Thanks for sharing these important KDE information! As a long time KDE user (not developer though :( ), I have been hoping we can see places of KDE on embedded device and I even talked with KDE guys about it when KDE 4.0 was just released. Although KDE team was busy shaping up KDE 4.X at that time, it seems KDE team have more time working on mobile world now.
I really like the way KDE is doing UI framework: one framework fitting all, but 1st question is how streamline KDE (or KDE SC :) ) can be? Actually it is also a question for MeeGo as the "core platform" already has >300MiB rootfs. Seems MeeGo will do something different according to architecture as each UX will have its own UI framework, i.e., my understanding is that an application specific to one UX will need some kind of porting (UI rewrite?) to work on another unless it is plain Qt application. Another question for both KDE and MeeGo is how QML (Qt Quick) fits in the whole picture? Will it be just another supported "program language" like python or javascript? Or will it be the primary way to develop MeeGo application (probably it won't for KDE)? I do like the way QML handles UI design after trying out Qt 4.7/Qt Creator 2.0 TP, btw. Thanks. JD Zheng On Wed, Apr 14, 2010 at 11:26 AM, Marco Martin <[email protected]> wrote: > Hi all, > > It's a while I read this list, I still didn't seen big discourses about > what > the user interface will be (what should be in a short term or in a long > term) > for the various versions (being Netbook, Handset, Connected TVs, ...) there > will be of MeeGo. > > I am (besides being a fan of the MeeGo effort ;) a KDE developer, in > particular I'm working on the Plasma project. > Now, it's a while we started some other efforts under the plasma project. > Why this is important here? > We aim to bring an unified experience across an eterogeneous spectrum of > devices, from desktop to netbooks and moile devices, with a quite different > UI > for each device of course, but with a similar look and feel and an high > degree > of code sharing via a common framework. > This is of course a goal that shares many points with MeeGo, that's why as > a > base system is a very important for us (without forgetting the traditional > Linux distributions, but for targets like handsets MeeGo is honestly the > best > way to go at the moment). > > The Plasma library offers several things that we really believe will make > pretty easy to achieve this goal, so first of all, what is Plasma? it is > several things: > > - A widget library on top of QGraphicsView: we have a common set of widget > based on that technology with a pretty simple and clear api and a common > SVG- > themed look and feel. Some of them already have optimizations done to > target > touchscreen devices, like "flicking" support in widgets that are meant to > scroll contents. > It must also be said that being QGraphicsview based, will be really easy to > mix and mash them with other things that use the same technology, like > other > widget sets and the upcoming QtQuick > > - It also provides a good model/view style separation (what we call data > engines): Many of our Plasma widgets display contents of online sources, > such > as weather services, news sites or social networking sites. The > visualization > of the data and the actual data fetching (and submitting) is done by > different > plugins, so it's really easy to have totally different visualization > without > having to deal with web services data handling multiple times. makes really > easy for instance provide different user interfaces on different target > devices, or doing mashups of data coming from different sources in ways the > original authors of the data engines didn't imagine. > > - Sharing: we have a working protocol to export widgets from a machine to > another, allowing for instance users to share an app between two mobile > phones, having the data coming into the app on the "receiving" device > perfectly syncronized with the data coming into the "sharing" device. It is > possible to share things between any two devices running plasma, even from > a > mobile phone to the desktop for instance. > An example can be found at > http://www.notmart.org/index.php/Software/A_remote_notification > > - Bindings: Being Qt based, the primary language is C++, but we have also > bindings for Python, Ruby and Javascript. Of particular interest are the > Javascript bindings: they offer only a limited api, giving access only to > "safe" functions, offering a pretty good sandboxed environment. > > - And of course the final product, the shells: the first big application > written using plasma is the KDE Desktop shell, and is the one used more, > but > we never made any assumption about having a "desktop" in the framework. > Recently new ones have been started: the Netbook shell, that saw a first > release with KDE SC 4.5 and still on an early stage, the Mobile shell and > the > Media Center. > > The Plasma Mobile shell is at the first stage of development, that started > during a meeting of a week in February. It's pretty impressive what we got > in > just a week and only two-three people working on it, since then the project > progressed even more. > Some description and videos can be found at: > http://www.notmart.org/index.php/Software/A_mobile_Tokamak > http://blog.morpheuz.cc/28/02/2010/the-mobile-concept/ > > http://labs.trolltech.com/blogs/2010/02/28/tokamak-4-the-kde-plasma-meeting/ > As can be seen from the videos, interestingly enough the devices we were > targetting back then were a Jax10 running Moblin and a Nokia N900 with > Maemo5, > the two parent platforms of the MeeGo project. > > > Other areas of KDE are making a nice progress, to become more usable in > scenarios definitely away from the typical desktop use case: the KDElibs > framework is being streamlined and modularized even more, in order to be > able > to have different profiles, from the "full" one that will be on the desktop > to > more lightweight on devices like tablets and netbook and finally to the "as > minimal as possible" profile reserved to handset devices like mobile > phones. > > Since it's getting pretty long, I think that's quite exaustive as an > introduction of the work we're doing, if you ave any doubts on the details > don't hesitate to ask. > I hope in the future we will be able to have a good collaboration :) > > Cheers, > Marco Martin > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev >
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
