[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Review of the branch plasma/declarative in kdelibs
From:       Marco Martin <notmart () gmail ! com>
Date:       2011-02-23 18:40:29
Message-ID: 201102231940.29663.notmart () gmail ! com
[Download RAW message or body]

On Tuesday 22 February 2011, Ian Monroe wrote:
> On Tue, Feb 22, 2011 at 14:41, Marco Martin <notmart@gmail.com> wrote:
> > Hi all,
> > in kdelibs there is since some time a branch called plasma/declarative
> > that contains a new little library, that depends at the moment on
> > kdecore and kdeui (probably is possible to make it depend only from
> > kdecore) that is meant to be used in QML applications.
> > see http://mail.kde.org/pipermail/kde-mobile/2011-January/000301.html
> > there is still quite a bit of work to be done on it (mostly integrating a
> > bit of similar work that has been previously done in kdepim) and i plan
> > to look into it shortly.
> > 
> > The target is to have it in experimental/ in kdelibs for 4.7, so I want
> > to ask for a review period for a subsequent merge
> 
> I understand the need to provide to the QML developer stuff like i18n
> and a way to look up the location of icons, but I'm less sure having
> an actual QIcon/KIcon object. We're going to want to make use of Qt
> Components right? So until thats sorted out and we're able to
> "sub-class" (re-implement? javascript is weird) the Qt Components to
> add features like naming icons by name, wouldn't it make sense to just

well, as Artur said, they won't really offer a subclassable implementation, 
rather example implementations and a reference api

> provide a method to query for resources like icons? And then let the
> QML developer use whatever the standard method is for displaying that
> icon.

there are 2 separate issues there: manipulating and display

* a thing that is to be seen if it's needed or not, is manipulation of those 
types within javascript, if it's needed for instance to create a qicon, modify 
it, assign it as property of other objects...
for qicon could be debatable and i could leave it in the specific plasma 
implementation, kconfiggroup for instance instead seems really useful to have

* to display an icon, there is an approach in a branch of runtime (so doesn't 
have much to do with this library), implementing items that paints qicons 
themselves.
now probably the best approach for icons loading would be implementing a 
QDeclarativeImageProvider i think (and that approach could go in this library) 
so it could be done with sometyhing like

Image {
	image: "image://icons/konqueror"
}

i still think implementing elements to paint qpixmaps/qimages, if the c++ part 
needs to feed one of them to paint is needed.


Cheers,
Marco Martin
[prev in list] [next in list] [prev in thread] [next in thread]