DevHeads.net

Review of the branch plasma/declarative in kdelibs

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 <a href="http://mail.kde.org/pipermail/kde-mobile/2011-January/000301.html" title="http://mail.kde.org/pipermail/kde-mobile/2011-January/000301.html">http://mail.kde.org/pipermail/kde-mobile/2011-January/000301.html</a>
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.

Cheers,
Marco Martin

Comments

Re: Review of the branch plasma/declarative in kdelibs

By Ian Monroe at 02/22/2011 - 18:11

On Tue, Feb 22, 2011 at 14:41, Marco Martin < ... at gmail dot com> wrote:
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.

Thanks,
Ian

Re: Review of the branch plasma/declarative in kdelibs

By Marco Martin at 02/23/2011 - 14:40

On Tuesday 22 February 2011, Ian Monroe wrote:
well, as Artur said, they won't really offer a subclassable implementation,
rather example implementations and a reference api

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

Re: Review of the branch plasma/declarative in kdelibs

By Artur de Souza at 02/23/2011 - 07:54

Quoting Ian Monroe < ... at monroe dot nu>:
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 :)

<a href="http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-200" title="http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-200">http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-200</a>

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,

Re: Review of the branch plasma/declarative in kdelibs

By Ian Monroe at 02/23/2011 - 10:49

On Wed, Feb 23, 2011 at 05:54, Artur de Souza < ... at kde dot org> wrote:
Yes ^^ that would make sense.

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

Re: Review of the branch plasma/declarative in kdelibs

By Artur de Souza at 02/23/2011 - 12:47

Quoting Ian Monroe < ... at monroe dot nu>:
Because they will have the look&feel of meego and we have our own look&feel :)
MeeGo also have some widgets that are only useful when using that platform...

Cheers,

Re: Review of the branch plasma/declarative in kdelibs

By Marco Martin at 02/23/2011 - 14:10

On Wednesday 23 February 2011, Artur de Souza wrote:
and, (at least until some time ago, didn't try a more recent version also
because still not public) relied on running in the opengl graphicssystem to
have a good performance...

but aside this implementation detail, yes, the point of qtcomponents is to
give a common api to allow platform specific implementations rather than one
set of widgets to rule them all

Cheers,
Marco Martin

Re: Review of the branch plasma/declarative in kdelibs

By Aaron J. Seigo at 02/23/2011 - 13:25

On Wednesday, February 23, 2011, Artur de Souza wrote:
note that Plasma supports per-device/target QML files.

that means that if you wish, you can provide a QML file for your Plasmoid that
is used when on "plasma" and a different one that is used when on "meego".
this happens 100% transparently to the Plasmoid which just asks for "the UI
define in the file call foo". Plasma does the work of picking the "right"
foo.qml file. all that is needed is for the QML files to be locate in the
correct path(s) in the package.

you can have QML files that are shared for the different targets. e.g. you
could have a QML file that is used regardless of platform, plus one if running
on MeeGo or Plasma or $WHATEVER.

very flexible.

this allows us to get around the "but this one piece needs to be different on
that one device" without rewriting the whole app or even having to create and
ship different packages.

one package, one code base, multiple UIs for multiple targets.

btw, no other system out there does this right now. and some, including
handset manufaturers, have tried for years.

so we can have a set of plasma components and a set of MeeGo components on
different targets and the same plasmoids on each, both getting the most out of
the platforms. we can also offer "compatibility QML" to the MeeGo Components
on non-MeeGo platforms.

so from the Plasma perspective, this isn't really an issue. we have a few ways
of dealing with it. the multi-UI thing is probably one of the most effective,
however, as it allows target relevant UIs.

Re: Review of the branch plasma/declarative in kdelibs

By Thiago Macieira at 02/23/2011 - 13:14

Em quarta-feira, 23 de fevereiro de 2011, às 13:47:49, Artur de Souza
escreveu:
MeeGo components will only be available on MeeGo.

You can make a compatibility layer in Plasma so you can run MeeGo QML apps,
but that's a separate issue.

The cross-platform API won't be called "MeeGo". That's the API that needs to
be implemented on each platform.

Re: Review of the branch plasma/declarative in kdelibs

By Stephen Kelly at 02/22/2011 - 17:15

I don't know anything about the code technically (looks complex) but a lot
of it uses the wrong licence.

Re: Review of the branch plasma/declarative in kdelibs

By Marco Martin at 03/28/2011 - 11:05

On Tuesday 22 February 2011, Stephen Kelly wrote:
Hi all,
an update on this issue,
I had got permission from the authors to relicense under the LGPL all the
files that were GPL.

If there are not significant issues, i would like to move this into master, in
the experimental folder, meaning changes will still be possible until it exits
from that folder.

Cheers,
Marco Martin

Re: Review of the branch plasma/declarative in kdelibs

By Marco Martin at 04/03/2011 - 08:12

On Monday 28 March 2011, you wrote:
going to land monday if no one speaks up

Cheers,
Marco Martin

Re: Review of the branch plasma/declarative in kdelibs

By Marco Martin at 02/23/2011 - 14:47

On Tuesday 22 February 2011, Stephen Kelly wrote:
argh, i see :/
so there is i18n files in gpl (Aaron, you agree on relicensing them? ;)

and backportglobal.h, that is gpl as well and seems to come from Qt, and that
is more of a problem :/

Cheers,
Marco Martin