Linked by vivainio on Thu 14th Oct 2010 11:31 UTC
Permalink for comment 445054
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 06/18/13 22:33 UTC
Linked by Anonymous on 06/18/13 22:26 UTC
Linked by Thom Holwerda on 06/18/13 22:25 UTC
Linked by Thom Holwerda on 06/18/13 17:45 UTC
Linked by Thom Holwerda on 06/18/13 17:32 UTC, submitted by poundsmack
Linked by Thom Holwerda on 06/17/13 17:58 UTC
Linked by Thom Holwerda on 06/17/13 17:52 UTC
Linked by Thom Holwerda on 06/14/13 21:03 UTC
Linked by Thom Holwerda on 06/14/13 20:46 UTC
Linked by Thom Holwerda on 06/14/13 17:32 UTC
More News »
Sponsored Links



Member since:
2005-07-06
yes, it's a fair amount of work. which is why i'm giving us up to 2 years to get there. that gives us enough room to work on other things as well and not rush.
it isn't a new start at all. a lot of code is re-usable, and the code that uses QPainter should get a lot simpler with QML.
the design of libplasma when it comes to things like DataEngine, Service, Applet, Corona, Containment, Svg, FrameSvg, etc. all stand without change in this. it's a change in the presentation layer, and yes, it is admitting that what we have now is not as good as it could be. that also doesn't mean what we have now is crap, just that we can make that part of it better.
there are significant implications for the python and ruby bindings, yes. finding a way to make QML work nicely with them is not a solved matter at this point, but it also isn't a problem that anyone has looked into extensively either. that's something that is only starting to be done.
i do think it should be possible, but then again .. there is a reason i've been encouraging people to move to Javascript for Plasmoid development.
those costs are why we are looking into this early (QSceneGraph isn't in Qt yet and its exact future is still under research; QML is brand new and libplasma will only have deep integrated support for it in KDE Platform 4.6). it's not a light set of decisions to take.
the good news is that we have a couple of years to do this in. personally, if i was working on a plasmoid, i'd make the move to QML when i wanted to do some work on the user interface presentation, meaning it would be already some of the work i'd be doing.
we aren't forced to move to QML or to QSceneGraph. they are new options, and they are compelling enough that we are electing to use QML more and more and investigate QSceneGraph as a serious future replacement. nobody is forcing our hand. we're also involved with the toolkit below us.
similarly, people writing Plasmoids today can continue to not use QML in the near term. so these changes aren't forcing any changes in the immediate.
it's very important to me that we retain as much effort as possible put into plasmoids that exist (there are hundreds and hundreds of them out there) and make any migrations as easy as possible.
one part in achieving that is sharing our decision making processes early and openly. plasmoid developers should feel very welcome in joining in on that conversation.
indeed