[Kde-pim] using qml from KDE applications

[Aaron J. Seigo]

great to hear that things are moving nicely at the sprint and that these 
rather important issues are getting attention! rock on, people...

On Saturday, November 20, 2010, Marco Martin wrote:
> We all know the problem about the lack of qscriptengine access from qml..
> and even if the access was officially there, there are still missing
> things, basically types that are not qobjects, in particular:
> 
> * KConfig
> * i18n
> * K(Q)Icon
> * KUrl
> * KStandardDirs
> * QPixmap (qimages too?)
> 
> and possibly other things.. any suggestions? 

i can't think of anything more for QML at the moment (other than things 
plasmoids need, but that's perhaps out of scope here). 

for general QScript bindings i can think of a lot more. but that's a topic we 
can tackle later on, even though it looks very, very similar to this one.

> (i would rather add stuff
> when needed rather that add everything that comes to mind)

agreed. it saves work and keeps the code small. we can always add, but 
removing is difficult or even impossible.

> now, this is just stuff from kdecore (and something from Qt itself
> that is unfortunately missing) so it should be in that place of the
> dependency chain.
> 
> so, what is "it": right now the Plasma declarative script engine does
> the following things:
> - obtains the scriptengine pointer from the declarative engine
> - makes the root object read/write
> - registers constructors for the mentioned types
> 
> would be nice if this is done by a library that can be used by all kde
> apps using qml, so the possibilities are:

well, i'll start with the last option: 

> * last option, the more modular would be doing a little library, in
> kdelibs but built as a separate so, that would be either a subclass of
> QDeclarativeEngine or a separate object that accesses the engine and
> does all the necessary registration.
> If an application needs to bind extra stuff not registered from that
> class it could still access the engine and do whatever it needs with
> it.

this strikes me as the most sane approach right now. i don't know if it is the 
best long term solution, but as an intermediate "what we need now" it could 
well be the best. if the provided API made it easy to bind additional things 
to the QDeclarativeEngine that would be a nice bonus, and it should be 
achievable without much fuss.

imho, a more compelling approach, if there is one, would require larger 
changes to kdelibs to be worthwhile. i think this is achievable for a 2012 
release, but it isn't something we can reasonably consider now.

well, here are my thoughts on each of the other options that were enumerated, 
but you can stop reading here if you don't care about anything more than my 
"aye" vote ... ;)

> * as low as it can get: kdecore cons: qdeclarative pulls in linking to
> -all- qt modules

this is not an option: kdecore must remain non-gui.

> * kdeui: would be in a library with other things like qwidgets,
> doesn't seem so good (and that lib has too varied stuff already)

yes, see more on this topic below ...

> * libplasma: the easiest place to implement it is in
> Plasma::DeclarativeWidget, but would mean everybody should like to
> plasma for that. Now, theming seems something that most of the kde
> apps would need (especially in the angle of unified kde wide
> qtcomponents) package fallback chain to load different qml file seems
> useful as well.

> However, it would mean linking to libplasma (and
> kdeui, and anything else that plasma depends).

plasma depends on a lot less in the mobile profile, so this is a lot less of 
an issue there. 

the major remaining annoyance on mobile for libplasma is the kdeui reliance. i 
don't see that changing, however, until two things happen:

* we get QtComponents rocking the house, at which point kdeui/widgets needs to 
be rethought

* kdeui gets a make over for mobile; e.g. most of the things in dialogs/ and 
paged/, much of what is in utils/ and everything in xmlgui/ directory is 
fairly specific to a specific target (desktop) right now. kdeui is both a 
platform target library (where the platform is KDE-as/on-a-desktop-env) and an 
app dev framework, and until that's sorted out it'll remain inconvenient as 
some things (app dev framework) we will want to contiue to use and the rest is 
just overhead on mobile

most KDE mobile apps are going to be faced with this same set of choices: use 
libkdeui and get a lot of useful stuff, or go a Qt-only approach and face 
writing more code and having fewer features but a more justifiable dependency 
chain. as libkdeui only depends on libkdecore + Qt (gui, xml and dbus), the 
"more justifiable dependecy chain" is already not as strong an argument as it 
might otherwise be.

what is the current situation for applications that link against libplasma 
now? well, they don't fall over or otherwise become worse off for it. while i 
understand the instinctive reaction against linking to not just another 
library, but "that stinky thing everyone bitched about for a couple years" 
(undeserved and unearned, but none-the-less what happened), it would be good 
to go through some real considerations before making a decision. what is the 
overhead on mobile for pulling in libplasma? on the desktop? these are 
questions we'll need to eventually have answers for.

i also think, though this may be personal bias speaing, that KDE apps that go 
for mobile could do a _lot_ worse than to consider using libplasma in general. 
DataEngines are not a good fit for Kontact Mobile, but much of the rest would 
be. it it is probably "too late" for Kontact Mobile at this point, but it 
maybe worthwhile to perform "early interventions" with other projects that 
start considering mobile later on.

> For the libplasma2
> thing could even make sense splitting painting/graphical stuff from
> dataengines and what not (without the symbols of the widgets the lib
> size should decrease a bit as well)

this would make sense (as in: justify the overhead, both for development as 
well as at runtime) if the two things are used separately in the common case. 
right now, they aren't. every app that uses one side of that proposed split 
also uses the other.

it seems sometimes people get lost in the "make the library focused" concept 
while forgetting that drives the definition of "focus": the applications that 
use them.

i'm so far unconvinced that there is any worthwhile saving to such a split in 
libplasma given how it is used. so far, i don't see anything to indicate that 
will change significantly. application authors who think "we only need the 
painting bits, there is no use for those other pieces" are likely doomed to 
replicate at least of the "other pieces", e.g. packaging.

what could change this is a rethink of what libkdeui itself is supposed to be 
doing/providing. if libkdeui was reorganized into 2-3 libraries (e.g. legacy-
free app dev, QWidget stuff, platform target stuff?), then the legacy-free app 
dev lib could probably also absorb pieces of what is currently in libplasma 
such as the packaging and declarative support.

this will mean a non-trivial amount of thought and effort to get it "right". 
in the meantime, perhaps we can consider keeping stuff where it is right now, 
live with it as an intermediate state of affairs and get the features in the 
apps we need.

i'm concerned that if we start pulling libplasma apart right now, we'll just 
end up doing it again in 2011 with a different arrangement, and probably with 
more mess.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20101120/625d7c8a/attachment-0001.sig