In the KDE Plasma Workspace 4.6 there was for the first time the possibility to write Plasmoids completely with a mix of the QML declarative language and Javascript, part of QtQUICK, this makes development dramatically faster (and with dramatically I mean that in around 2 days, c++ plasmoids developed since 4.0 can been rewritten from scratch)
Now, for 4.7 we are increasing even more the capabilities of the QML script engine, with the target of being able to write any kind of complex user interface with the QML/JavaScript languages in conjunction with the Plasma API.
The last addition is declarative containments:
In the Plasma workspaces, the activities are represented by spaces for the widgets, that can be very different, just think about how different they are the appearances and layouts of the Plasma Desktop shell, the Netbook and the Mobile ones.
The way in which the Plasma widgets UI components are loaded, shown and managed is quite important for the final user experience of a particular device, and has to be pretty specific and tailored to the particular form factor.
On the desktop shell, everything on the desktop it’s information always with you, wispered in the background, where everything is freely positioned and resized (also due to the large space available)
On the netbook, we have a different use case and a different hardware: a free layout wouldn’t work there because of the screen real estate, and because a desktop would be almost never visible there, so all the information is in a big scrollable page, that can be brought any time in front of all the other windows.
In the mobile/handheld shell, the same concept is brought even further: the widgets can zoom to full screen, having two modes, a non interagible, reduced view, to a zoomed, interactive mode, due to the extreme small size of the screen.
Now what’s missing? lately the tablet form factor is exploding, that means the need for an ui adapt to a 7-8 inches touch screen without keyboard.
On a such form factor, the approach of zooming to full screen followed by the handheld shell wouldn’t be optimal, but we had another idea there.
A first prototype of the idea we developed now was already seen in a prototype based on the netbook shell and newspaper containment in 2009. The tecnique for managing the widget was later chosen as well from the MeeGo tablet UX, even if the approach on the widget themselves is radically different (here there is a fixed set of widget that represents the main kind of media the device can handle, like pixctures, music and video)
This has now been rewritten as a stand alone containment completely in QML (with the code size a fraction of the original)
A video of a preliminar version can be seen here.
The goal there is to show to the user a quick glance of all the data the user usually works with in all the activities (yes, that word again;) he does usually with the device, with the possibilities to expand all those little previews in a proper full screen touch friendly application.
In this video you can see as well other new things that I still didn’t write about… that’s for the next time, stay tuned 😉
That looks and sounds really promising. When MeeGo products start shipping I really hope that we can, at some point, easily install these alternative shells. Which brings to my question, in what kind of phase are we regarding Plasma MC, Tablet and Phone workspaces? Is it possible to estimate when they are ready for prime time?
Hey, I’m really looking forward to see it in action! The MeeGo Tablet UX is nice concept – actually, this comment is written on Tablet UX pre-alpha (while studying it;-). But still I think – plasma-netbook and plasma-tablet should merge…
Great Work!
I’m trying SAL, is amazing, fantastic.
In the future, why not implements it in Plasma Desktop via popup instead Kickoff?
Why the Plasma is so laggy always? I have not seen any computer capable to run it smoothly. I mean those very small glitches what gets when doing anything. It has always disturbed me and makes wonder why it is so.
I just think plasma does not preload those graphics at all to get them smoothly drawed…
What you forget to say is that any non-trivial plasmoid requires a DataEngine which is still written in C++. So it is exaggerated to say that QML dramatically reduces the development of plasmoids. I guess that in those 2 days you didn’t count the work done to write the DataEngines. My experience with QML is that while it does reduce the development time (and it is a great technology!), the development time is not dramatically reduced (especially if you want your QML app to have a decent design).
Please, make available the Tablet Plasma form factor in every computer in Linux. I dream to use it with my Pavilion tx1000.
@g: you don’t need to write your DataEngine in C++. depending on what you need (e.g. network access or access to a system level only-in-C library) you can do so in Ruby, Python or Javascript. furthermore, writing the DataEngine is usually the trivial part given that it is nicely separated from the UI, is data-only and uses the DataEngine API which keeps the nastiest of details far away from the developer.
as for time taken to get a nice design in QML, this is true of any UI. the question is how long it takes you to go from that nice design to a working implementation, and this is where QML an really shine over the procedural method employed in C++ or even straight JavaScript.
@Jaroslav Reznik: it is possible that Tablet could “obsolete” Netbook, but i think there is still enough difference between the form factors that they will remain distinct. the primary difference is how Netbooks come with a hardware keyboard and a pointing device.
however, there is something important to remember about Plasma: it is highly componentized and those components are highly re-usable. one does not need to merge two applications to be able to re-use the vast majority of code. so instead of having one shell UI that kinda-sort fits multiple form factors, we can actually afford to have multiple shells that fit each form factor very well.
@pusu: MC is still indefinite; people poke at it from time to time and it progresses, but not with a consistent enough pace to really know when it will emerge as “ready”. Mobile and Tablet are our next focus areas and we have 2 in person meetings in the next 2 months to discuss more precise timelines for them. we’ll keep everyone updated as that unfolds.
@aseigo: yep, I know… It’s more issue on netbooktablets (netbook + tablet like Lenovo S10-3t). Original Plasma-netbook is nice for netbook like and some tablet like work but it’s completely killed by small panel on top – it’s not accessible by touch.
And yes, I really like the flexibility of Plasma to create own workspace that fits my needs but it’s still rough.
@Jaroslav: that’s true and could be that the netbook gains some more touch friendly featured in the panel, however they are really for different targets.
those hybrid devices like the s10-3t are interesting indeed, they don’t seem to have an huge succes tough. I think that the reason could indeed that they have two completely different usage patterns that makes that an ui that works in netbook mode doesn’t in tablet and viceversa.
I would say that right now the tablet shell could work better on a netbook than vice versa.
however, if netbooks don’t completely vanish from the market i the next few years, I think two different shells will remain (sharing a lot of components tough, the tablet uses the netbook search and launch atm for instance)
RE: Tablet Plasma: this is of course in our public git repo, so anyone can build it on his pc. if distributions will package it will be even easier to try it anywhere 😉
RE: Laggy?: actually the video makes it look slower than it is… it’s not bad at the moment but also not very satisfying, there’s just so much a mostly software rendering based canvas can do. That’s the reason the scenegraph replacement of QGraphicsView is in the works and we are designing a libplasma2 that would take advantage of that fully hardware accelerated canvas.
RE: Leonardo: there is a little technical problem that makes moving SAL in a popup non trivial.. however if it will be rewritten in QML it should become much easier to provide a popup version.
RE:ETA: As Aaron said, it’s early for this (at least seems that now the development is really taking off) there could be some good announcement about it in the next few months so stay tuned 😉
@Aaron: I didn’t know that you can write DataEngines in other languages too. Interesting. I have now discovered examples in kde:kdeexamples/plasma/*/dataengines.
I agree that you need time to design the UI when using any programming language. What I wanted to say was that when the OP says that “in around 2 days, c++ plasmoids developed since 4.0 can be rewritten from scratch”, I read this sentence as “all the time needed to design the plasmoid, write the UI in QML, write the DataEngine, … fits in 2 days”, which is not true (or you must be working really fast, much faster than me). On the other hand, I totally believe (based on my QML experience) that starting from the existing design and using the existing DataEngines you can write the UI in QML in 2 days. So my point is: yes, QML greatly reduces the time needed to implement the UI, but the other parts of the work (design, DataEngine) are not reduced in time. By the way, I am extremely happy with the choice of QML as the default language for plasmoids.
Can somebody please tell me where I can find that beautiful orange/purple/pink wallpaper?
Thanks in advance
Great work, I like it. sito hogan http://www.scarpahogan.com/
Great Article! Well-articulate on explaining the true state of tablets in the market right now!