[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:       Artur de Souza <asouza () kde ! org>
Date:       2011-02-23 11:54:59
Message-ID: 20110223085459.13563uqonvjvzm2o () morpheuz ! cc
[Download RAW message or body]

Quoting Ian Monroe <ian@monroe.nu>:
> 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
> 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.

Just as a side note: Qt Components right now is just a specification  
of a common API for widgets so there is nothing that we provide that  
could be "subclassed" for example :)

http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-200

Qt Components will also not provide something like "naming icons by  
name". In order to have this, KDE will need to provide a "image  
provider" that would be able to return QPixmaps when one asks for an  
icon by the name.

My tip would be: don't expect much coming from the project itself  
besides the API that should be followed by developers implementing  
their platform's widgets (this API can be extended though).

Cheers,


-- 
-------------------------------------------------------
http://claimid.com/morpheuz
Blog: http://blog.morpheuz.cc
PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net

-------------------------------------------


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