Review of the branch plasma/declarative in kdelibs

[Ian Monroe]

On Wed, Feb 23, 2011 at 05:54, Artur de Souza <asouza at kde.org> wrote:
> Quoting Ian Monroe <ian at 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.

Yes ^^ that would make sense.

> 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).

So should there be a Qt.components.plasma? Its not really clear to me
how Qt.components.meego would be inappropriate for Plasma though.

Ian