Merry Chrismas Planet KDE and everyone else 😉
For the occasion I’ll link again a cheesy tune I wrote several years ago with Milky Tracker (that in the meantime was open sourced, yay;), a beautiful retro application for writing the Amiga-derived MOD and XM retro-tastic music format.
Here It is 😉
It’s always hard to get a real firm impression on something at the first shot of an unfamiliar new thing, but i can say that it has been a really good conference, at least the impression was of a warm and friendly community even if the organization was on an huge scale (having a *stadium* all for us was kinda a weird feeling, as the meego commercials at the sides of the playing field during the football game, geekiness in the most ungeek place :p) and the netbooks/tablets are quite sweet too 🙂
As the KDE side, I am seeing quite a lot possibilities of collaboration. So far most of the problems seems to revolve around one thing. Awareness. I’ve seen many times real interest after a quick chat explaining what KDE actually is.
Unfortunately KDE is seen as that big monolithic project completely desktop specific…
As soon we started to talk about the kde-mobile modularization effort of kdelibs, the multiple shells of Plasma (Plasma as a building block set to make greatly customized workspaces for any kind of device and/or simple fullscreen applications that can dynamically load a different ui for each profile)
So, in the end was quite educational for everybody. It did let us discover more about what MeeGo, how it works, and what their parts are, and many of the MeeGo community find out about what KDE is. Two communitites encountering without colliding. Great!
Today I’m in Berlin at the KDAB office. They were so kind to host an happy bunch of KDE people to discuss and develop with a mobile target in mind.
Given that almost everybody here has that tablet, expect nice demos and videos of some surprising use of that tablet later this week, alongside (finally!) real packages to make easy for everyone to try KDE on MeeGo.
Wanna some teasing?
Plasma tablet UI prototype:
KDE games: Palapeli
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.
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:
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:
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.
As I described in the latest entry, with the KDE Plasma Workspace 4.6 there will be a new feature that will be a key one for the future evolution of the Plasma platform: the ability to write plasmoids with just QML and Javascript.
So, let’s try to see if it’s possible rewrite the average widget in with the declarative scriptengine…
We have a dataengine (using a neat library called Attica) that can query the various functionalities of websites that offer an API compatible with the Open Collaboration Services, such as OpenDesktop.org. One of the features offered by this API is the Knowledge Base: users subscribed to the site can ask any question (in topic with the website) and other users can answer to them. Plasma offers a desktop widget that can query and visualize those question/answers. It’s written in c++ and is about 400-500 lines of code.
How much QML code would take to write a very minimal Declarative Plasmoid that can access the knowledge base entries trough the Plasma dataengine? Here it is
import Qt 4.7
import org.kde.plasma.core 0.1 as PlasmaCore
ListView {
clip: true
width: 200
height: 300
PlasmaCore.DataSource {
id: source
engine: "ocs"
source: "KnowledgeBaseList\provider:https://api.opendesktop.org/v1/\query:opendesktop\sortMode:new\page:0\pageSize:10"
interval: 120000
}
model: PlasmaCore.DataModel {
dataSource: source
key: "KnowledgeBase-[\d]*"
}
delegate: Text {
text: Name
}
}
24 lines 😉
What is important to look here is the DataSource{} definition that defines to what engine we’re connecting and to what source. And the DataModel{} that hooks up what has been fetched by the DataSource to a suitable model for the use by the ListView.
Let’s expand from this to something that can be compared to the C++ version in terms of functionality. You can download an early example of the code from here. (all is available from the playground svn repo). It’s still early to include it in the 4.6 release for various reasons, but the path is definitely clear 🙂
Here you can see a brief screencast of the two plasmoids, the C++ and the declarative one working side by side.
Here is a video tutorial that explains the steps taken to write this plasmoid.
It is also a little demo of the Plasmate IDE that while it’s still at early development stages, it’s pretty impressive already: all you have to do is write the code and test it in the preview side panel. zero worries about creating the package structure, desktop files or installing :p
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:
So, what will have the KDE Plasma platform 4.6 of all of this?
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.
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:
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.
After the usual 6 months cycle we made it. KDE Development platform, Plasma Workspace and various applications have reached version 4.5 and have been released. It has been as usual an huge amount of work and sweat, but this is release i think we can be proud of. It’s the point where we see all our little creations reaching maturity, but this is just the beginning.
Work on Plasma Mobile continues.
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.