As previewed some time ago, the ongoing effort of porting the current stock Plasma Desktop widgets to QML isn’t not just recreating them and be done with it, but rather pushing QML a bit beyond of what it can usually do and give a platform to build user interfaces that can adapt to different kinds of situations and devices permitting of:
Shipping the user interface, graphic assets and JavaScript code in a simple package with a well defined and familiar filesystem structure: one single package that can adapt to any devices you want
For a given device, you must be able to customize and rewrite any part of the interface you want
But you should have to rewrite only the parts you need, nothing more, recycling all the rest
In QML plasmoids, we provide some mechanisms (plasmapackage:/ urls, plasmoid.file() function) that will load resources always from within the Plasma package (the single zip file you downloaded from Get hot new stuff, for instance) and always the proper one. What doe it mean?
Any resource you may need, that can be a qml file, a javascript file, an image, a sound… can be something shared between all possible platform targets, or something that is specific for a certain one. Not only this, you coul need as well for instance a file that is shared between a tablet and handheld profile, but not used in the desktop world.
this little video shows the rss news reader QML plasmoid (the usual guinea pig i use for this kind of experiments) loaded on a desktop, looking like an usual harmless desktop widget and as a standalone window, intended to be used on a tablet form factor device.
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)
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 😉
Disclaimer: this entry won’t talk about a certain thing happened those days, and I won’t in future entries as well, until there is actually something to talk about.
There is a thing that came to my mind some days ago, when i finally decide to fix a little visual inconsistency that was bugging me since some time.
In the KDE Plasma Workspace 4.7, the clock and keyboard layout indicator will look like this (landed in git earlier this week):
The style of the systemtray is now much more coherent, all thanks to a quite slight change of look in those two little elements, in the specific, text svg-themed themed like the systray icons (that is by the way usable by everybody since it has been placed in the public plasma api)
A thing that will come for 4.7, is a series of many small improvements of many little pain points, may be either a small missing feature, a fix of a little inconsistency, or, in any case something small, easy to contribute that everyone that is eyeingto start to do some patches can find as an easy entry point.
There are already some heroes that have joined and started to review all shipped plasmoids for some points of behavioural consistence. First step, now, thanks to them in 4.7 all plasmoids will have a working “apply” button in their settings dialog.
Here are two screenshots of Microblog plasmoids. There are two nice novelties that can be noted here (due respectively to KDE Plasma Workpace 4.6 and 4.7) are the support of “reply to message id” in the twitter API, so in Identica conversations will appear correctly threaded (sadly there is still no way to retrieve that threading information from the API) and the support for marking messages as favorites, that will appear in 4.7
On the right is the usual good old stock Microblog plasmoid, on the left it’s the plasmoid rewritten in QML+JavaScript. It is on early development but is probably going to replace the fomer (there are still some layout differences and details, all of this is going to get polished).
What’s nice is that in two days of development that plasmoid reached about 90% of the features the C++ counterpart gained in well, ages 😉 so I’m quite confident the development speed in Plasma will get a dramatic boost.
All of that code in in KDE svn playground repository, I will give more info when all will move to git together with the rest of KDE software.
We didn’t put or effort only in the mobile environment or the new declarative “way of doing plasmoids”, but the general polish of the traditional desktop shell, the “most immediate need” for users is quite high on our priority list too.
Chani recently blogged about the last progress of the activities management: in the Plasma Desktop workspace 4.6 finally the advantages are starting to be exposed to the user. In brief: can virtual desktops stop and start applications on demand when they switch? can an application be on 2 out of 5 vd? can a vd be stopped and when recreated be restored exactly as it was? (wallpaper, desktop widgets, running applications etc) can the user remove a non empty, non last virtual desktop? Can an application behave in a way that is specific for a certain desktop, like showing only work related contacts?
Answer to all of those question is a discomforting, deep, structural no. If we ask those questions for the activities, the answer become yes, and the difference of purpose of those two things becomes evident. virtual desktop -> spatial arrangement of windows. Activities -> what I’m doing. There really is little overlap between the two things. Spatial arrangement is often used as activity separation, but is condemned to remain an half backed solution.
Notifications
Yes, notifications again! There won’t be any very big turning upside down of the notification an job area for 4.6 The form it’s “stabilizing”, with minor tweaks that can enhance quite a lot the look and usability of it, let’s see in brief what 4.6 will bring to the notifications and jobs area:
Slightly revised look: better spacing, less visual noise, more pixel perfection
More compact layout of the jobs widgets
A speed plotter for job in the expanded view to be able to see what’s going on in the transfer of a single file
Global jobs progress bar is hidden when only one job is running
Notifications can be dragged in the desktop again
Only one scrollbar, and only when is necessary: everything scrolls and it’s preferred to keep visible active jobs rather than the notification history
Notifications history tabbar is hidden when only one type is present
Big icons in notifications to help to identificate what it’s talking about at a glance
Action buttons moved beside the test to have a smaller notification widget
It is possible to drag anywhere the notifications popup, so regardless of where the notifications Plasma widget is, they will appear in the place it works better with your workflow.
Since a picture is worth 3000 bullet points here are some screenshots 🙂
I already extensively talked on this blog about the new QML declarative AppletScript that will be present in the upcoming 4.6 release of the KDE Platform and how is important especially in the light of the QtComponents project.
A little new feature got in some days ago: in technical terms, is a fallback chain for Plasma::Package
Wait, a what? wtfbbq?
Let’s see what this means with this video 😉 Here you see some further developments over the RSS reader we seen the last time, like a search as you type filter bar and a bookkeeping of read/unread feeds (done with Plasma::Storage, a projects of the last Google summer of code).
But wait, there are 3 rss readers shown in that video!
The other two, shown as standalone windows, they have a very similar and coherent behavior compared to the one on the desktop, but they look completely different and have some important differences in their behavior.
They are a version targeted to MeeGo Handheld and MeeGo Tablet (the one with a two column layout, that is possible in a larger screen)
Those two version, use a (very early and under heavy development) version of QtComponents for MeeGo, that in turn uses the MeeGo touch framework theming system to have applications with the same look and feel of native MeeGo touch apps, but with a QML declared interface.
What is really neat is that those are not 3 plasmoids: it’s only one, in a package that weighs less than 80Kb 😉
Also, the proper version is automatically chosen at startup by the Plasma package system (at the moment depends from an environment variable) in the code you won’t have to put explicit switches to discover what platform you’re on. You just have to provide the files for the proper platform in the proper directory, and they will be automatically chosen respecting the specified fallback chain.
Once this is in “full steam”, we will be able to have a set of plasmoids that are:
Traditional desktop widgets
more reduced widgets for the Plasma Mobile workspace
“Full apps” on standard MeeGo handset and tablet
“Full apps” on a different mobile system, for instance one completely based on Plasma Mobile.
How this can be done?
Plasmoids are distributed in packages, with a certain filesystem structure. In the javascript code you have, when asking for a certain resource, that can be an image, a javascript file, a QML file, you just ask for a particular include, you just have to ask for an “image” called “foo.svgz” for instance (plasmoid.file(“images”, “foo.svgz”) without having to worry about the actual path.
Now, (actually depending of environment variables) the actual path of the files depend from the device used, so you can decide for instance, that when you are working in a mobile environment to replace one of the package files with other one.
Files are searched from the more device specific to the more generic ones. In the example of the video there is the chain: MeeGo tablet (or handheld) -> “MeeGo generic” -> “completely generic” (where the Plasma-desktop case is treated as the most generic one right now since is the most common).
They can be qml files, images, ui files, svgs, whatever.
if the replacement is done carefully, you will be able to have even completely different user interfaces (in this example, MeeGo handheld and MeeGo tablet) but sharing the logic of the program, that can be Javascript, if the application is simple enough, or C++ modules if needed.
The image on the left is a new (example) plasmoid that marks an important change… this is going to be a quite massive blog post, with pretty technical details about what I think is going to be a feature of an higly important strategic relevance on the road towards Plasma as a mature and powerful platform.
The Plasma declarative bindings have landed into kdebase! This means it will be possible to use the new QML language part on Qt 4.7.
As Aaron noted some days ago, QML in conjunction with now in heavy development technologies like QtComponents (and in the future Qt cene-graph) will play a key role in the creation of user interfaces in the future, and gives us a very important puzzle piece we were still sorta missing.
So we deceided to be (as usual 😉 erly adopters of the technology and with the KDE Plasma workspace 4.6 the first pieces will be in place for the roadmap that will lead us basically to this path:
Separate the implementation of the logic from the user interface
Avoid C++ (and well, any imperative language) as much as possible for the UI
Be flexible, an application should be able to jump between different devices as easily as possible
do applications that can chose the proper ui amond different choiced depending on the device used, the screen size, the input methods and what not
With QtComponents, use what will be the native set of widgets/components for the given platform: on a MeeGo phone, use its own widgets, theme and UI paradigms, but a different interface somewhere else
Performance, perforance, performance, enter Qt scene graph
So, what will have the KDE Plasma platform 4.6 of all of this?
Use QML from C++ Plasma widgets
The first pass (needed to do the following one) is to have a way to easily load a QML file into a normal C++ plasmoid. Now, loading a QML file into a QGraphicsScene (and making it well behave inside the QGraphicsLayout based Plasma widgets) is a quite simple operation, however it is a bit long and repetitive amount of boilerplate code… enter Plasma::DeclarativeWidget.
This is a normal QGraphicsWidget just like the other Plasma widgets, all you have to do is to add it in the QGraphicsLayout of the applet, set the path of a QML file in it et voil
Have been quiet on the Plasma mobile land lately but this doesn’t mean there weren’t developments on that, as this small video, on the usual two ugly pieces of hardware, shows two quite foundamental those days features that recently got in.
Screen rotation, with a nice animation: so now screen rotation is supported both on devices that will rotate the screen in a “traditional” way, by actually rotating the screen resolution, and devices that will rely on the application painting itself rotated (such as MeeGo) in this case such kind of animation becomes possible.
Our on screen keyboard now has also a “compact” mode for mobile devices, you can see it there reduced on the smaller device and full on the bigger one.
More importantly, the keyboad knows when showing itself: when the user taps any editable text area.
Here it is also a smaller video that shows most of the things I’ve talked about in those months. (the nice musical background is by Nuno Povoa, made for the KDE4 launch)
When designing Plasma Mobile, it was immediately clear that wouldn’t have been possible to do a “one design fits all” application: mobile devices vould have come in pretty diffrent forms:
Different resolution
Different phisical size
That implies, different DPI
Different use cases: an internet tablet and a phone put the emphasis on very different primary functions
What we have seen right now, is the development of completely different code, from the ground up for different platforms.
In Plasma we always tried to avoid this, by having everything as a plugin, so it will be necessary to replace maybe the shell itself and just the components that really have to be changed.
With Qt 4.7 a new framework ha been introduced: the declarative UI, that permits to do quite fancy stuff in the QML language in a very short time.
So with the development of Plasma mobile we started an experiment, and here it is (usual VESA drivers disclaimer about the speed that applies to all screencasts done on that weird tablet):
Besides bindings to write plasmoids entirely in QML (or using QML bits into C++ plasmoids), the behaviour of the entire shell, how activities appear/disappear/are chosen is completely controlled by this language, so in theory should be enough to change the QML files set to achieve a completely different ui and behaviour.
In theory. But it gets interesting when this becomes actually practice: with just some adaptions to the C++ code of the shell to make it more flexible, last days I wrote a different QML set and a different default layout configuration aimed for bigger, but still touchscreen based tablets.
Those kind of devices always were for me one of the main targets of the netbook “Newspaper” containment, that’s why a quite big amount of attention has been put into the behaviour of “flicking” arouund things in it.
Here the pages concept is taken to the extreme: you can phisically change pace with a swipe of the finger, dragging the new one into the screen, as you would change real pages 😉
The search and launch interface is dragged in a similar way, but from the bottom, since it should always be quicly available with a single gesture, no matter on what page you are.
This is just a quick proof of concet, but that shows itself very promising for the future.
Bit after bit all the pieces come together: what’s impressing is how much the Plasma framework we have built into years is paying now.
Plasma Mobile still lacked a widget explorer: the particular formfactor really required a custom one since the one used in the desktop has a pretty different usage pattern and is targeted at a really different form factor (here we are targetting -really- small screen sizes).
I was expecting that writing one could take a quite long amount of time, after all getting there the firt time taken a fair amount of work…
I couldn’t have been more wrong. In less than two days I have now a working widget explorer, that works pretty well on small touch screens, using a mix of QML, Plasma Widgets and C++ models
The main interface is a big flicking icon grid, with a side panel that shows detailed informations on the widget (that can be scrolled with the finger as well).
To add a new widget into the screen, just click at the “+” icon positioned where the widget will be. Interaction wise is way simpler than the Plasma Desktop mechanism, because of both precision of the input device (where with device I mean a fat finger :p) and of screen size (where with size i mean actual phisical size, not pixel resolution)
This little video shows it in action on the usual device. ah, and a curiosity, at some point you see the screen switches to an activity with a big numeric keypad.. that’s not a mockup, as Artur announced during Akademy, if it runs on a N900 phone, that can do actual phone calls.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.