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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel