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
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
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.
Plasma has a wonderful theming engine, that enables the creation of a really stunning visual appearance, with a great amount of customizability, just look at what is available right now, to not mention that being vector based makes the widget set pretty flexible and able to be used on really different hardware form factors with different sizes and dpi.
But we’re developers and we like to write code, hack on stuff, we often forget to document things, and this is an area that really can get better.
Yesterday I’ve forced myself to look at the quite incomplete and outdate documentation for the Plasma theme system and I’ve looked file by file, element by element and completed and ordered the whole theme.
Now if you have any doubt on the Plasma theme structure, just go to the relevant techbase page, and you’ll find the complete list of every file and every element in every file, updated to the upcoming 4.5 release. this should ease a lot the construction of themes.
It has been a long and painful work, of which developers may really want to avoid it, but it incredibly pays the effort, because it’s a really important part of the elegance we are trying to reach. A complete, pretty and documented framework is what is elegant to a quite relevant part of our audience: developers that are approaching the platform for the first time.
Now we are restructuring the techbase page for Plasma, moving here the pages that makes more sense here, having the two wikis more in focus and comprehensible.
If you are interested, if you are trying to approach the development in Plasma and have difficulties to grok some of the concepts, if you already work on some plasma aspects such as plasmoids, just stop on #plasma on freenode and you can give an hand in the documenting effort, being tutorials, wiki pages or API docs, you’ll learn quite a lot of the internals in the process and will make easier for others to learn.
Memory is starting to be fuzzy already, so, since i promised a blog about the same topics on my talk about the netbook, here it is, mostly because the netbook project (but more important its implications in helping Plasma being ported and be optimized for a long spectrum of devices) has really soft spot in my hearth.
We started from the most familiar non-desktop platform: The netbooks, but…
Aren’t netbooks just underpowered little laptops? Indeed today are sold like that, with just still XP or Windows 7 preinstalled, but that’s the reason the interest in them is decreased recently. they are just not good general purpose machines.
But, they are pretty good as devices that can be used on the move to look at online content such as news, emails or social networks, and ultimately as a communication tool, rather that a content production workstation.
KDE SC and Plasma:why?
We still hear again and again that KDE is to heavy and too bloated to run on any modest hardware. Of course technically the situation can be improved and it will, for instance the platform profiles that are being cooked right now will be able to provide a law fat (as in Kevin words 🙂 you will find information about that in the upcoming future on the planet.
n the other hand, complaints are often not completely true, we need better communication about what the advantages of a KDE based solution are, and where the problems are: we pushes the edges of what all the layers of our platform can do, Being Qt, X, or graphics drivers, due to our hard beating the quality of the whole stack is really increasing (and this funningly enough is benefiting non KDE users as well).
About Plasma, it’s the primary UI on desktop, can be on completely different devices too?
Yes, because the Plasma library was designed with no assumptions on a particular form factor in mind. We started from netbooks to taste the waters, because was the less alien one and because we can provide a rich and complete user experience from day one.
What do you want?
Why Plasma can be good on a netbook, on a mediacenter, on a mobile phone?
because it can give people what they want, both to users that actually get to use it and developers, that want to create the most wonderful application in the world with it.
Users
So what users want? they want something useful. Now “useful” can mean different things in different form factors. On a netbook, and even more so on tablets and smartphones, is to be efficient instruments of communication and content fetching, perfect web clients, better than even just a browser.
They want to feel in control: the day for instance the facebook interface will change without them being able to choose they will get pissed, with rich clients there is always a slightly bigger degree of choice.
They want also something beautiful: between two systems that “just work” they will choose the one they find more aesthetically pleasing, even if it’s not technically the best, it’s irrational but it’s the human nature.
Developers
They want a powerful framework to build powerful applications as quickly as possible, Plasma offers a series of common components that makes the life of developers as easy as possible.
Plasma is heavily based on a strong separation between data and the visualization.
Everything in plasma is a plugin the data plugins are Data
Everything you see in Plasma is based on Svg, it’s theme engine makes easy to customize a potentially resolution independent widget set while maintaining pixel perfection.
Its widget set is based on QGraphicsView, like the other Qt widget sets conceived for the mobile, and is possible to integrate and use it together with them.
We have also a flick able scroll widget as well a flick able QtWebkit based one, that is very important, since the future on more and more devices is the touchscreen.
Plasmoids (or plasma widget, more generally), everything you see in a Plasma environment is one of those plugins. they can be specific for a certain formfactor, like kickoff or the taskbar, or they can be quite flexible, like the microblogging plasmoid.
They are done to work well in the desktop, panel, the netbook newspaper, as standalone little windows invoked from krunner (new from 4.5).
So, what about the netbook again?
First thing:window management: the desktop metaphor doesn’t work very well there…
KWin behaves slightly differently there, windows are maximized by default, maximize windows don’t have borders, and the panel is auto hide by default, so quite a lot of pixels are saved for the app
The boundary between primary UI and applications becomes blurred when some of the content can be fetched directly from the desktop, so it becomes a normal window like an application.
Search and Launch
After some usability tests done at Indt last year, what emerged is that Search is more intuitive than browsing trough many items in categories and subcategories. Search and launch uses all the search plugins of KRunner, even if is a completely different UI.
There is still a menu, but it’s flat, doesn’t have tree structure, that doesn’t work well on the human brain.
Of course uses flicking widgets and has an extensive support of drag and drop, that makes quite convenient to use it a mouse or even a stylus.
Netbook: Newspaper
Also the main widget view for the netbook is based on flicking widgets, this gives an infinite vertical space for our widgets, because the free layout of a desktop isn’t space-efficient enough for a small screen, so a layout that can be “browsed” like exactly an actual newspaper, feels more natural there.
Future
What the future reserves us? We need more widgets, especially PIM related, to make the “newspaper” really useful, a GSoc project is helping in this.
Also, the dataengines needs to cache their data for when the network connection is not available, there is a GSoc project working on this too.
Last two points, we need to expand on other devices, because I think netbooks won’t stay the way they are today, they will probably not converge with tablets, but for sure be strongly influenced by them, or become something even different.
Last but not least, the newspaper concept spawned some unintended at first but really interesting developments: two GSoc projects around Kontact and Skrooge, as well some work on KDevelop to provide a “dashboard” of useful widgets in standard desktop applications.
I gave my presentation today at 17:45, it gone pretty well, despite of the Germany argentina match at the same time (Martin’s KWin result plugin helped too eheh 🙂
Those are the slides, i hope to find time to write some more on that
I’ll give a talk at Akademy together with Alessandro Diaferia, so the topc can be easily guessable 🙂
We’ll talk about the adaption of Plasma to completely different use cases to its usual dress, that is to be the main user interface of a desktop system.
In particular i’ll talk more about the Netbook Shell and Alessandro will talk about the media center project.
I’ll leave Alessandro going in more details on the mediacenter, I’ll try instead to answer to some question, some generic, about porting plasma on different devices some specific to the Netbook use case:
Why netbooks need something different?
Why KDE SC is a good platform on non desktop devices?
What Plasma has to offer there?
What has to offer to users?
What about toys for developers?
What are the components of the Netbook shell and why they are designed the way they are?
It will be on Saturday 3 July, 17:45, at the mobile track, stay tuned 😀
I see last entry sparkled a bit of discussion, so a recap is needed on what are the goals of our redesign for the ground up of the systemtray, form the low level protocol to the visualization.
The systemtray was almost always intended as a “notification area” (this always was its official name) and most implementation until now failed at it. The Windows systray failed because every commercial application wanted to put its “brand” on it, the X11 systemtray failed even in a worse way, because there was zero communication between the applications and the systemtray and there was no semantics at all in the items.
So the visual representation had to be pretty limited, it could just put there all the icons that registered themselves and nothing else.
The “notification” nature was failed by the fact that is was just an huge disorganized list of everything and the kitchen sink, so the option to manually hide some of them got in. This was again a failing of the notification concept, a manually hidden notification item can’t notify anything right?
But hiding icons would not be a bad thing if you can ensure that the ones that are actually notifying something are indeed visible, so -manually- hide/show icons can’t work.
That’s one of the reasons we wrote a whole new protocol for those items, called StatusNotifier (and -not- sytemTraySomething), this is already being implemented from third parties, for instance the next Ubuntu release will make extensive use of it. In the new protocol, an item is in a passive state unless it decides it really needs to be active (i.e. has some useful status information, like the battery charge) or is notifying something really important (like, the battery is running out).
Any information that doesn’t belong to the latter two cases, simply should not be there, as well doesn’t belong there its usage as a tiny taskbar, that will go completely away in the future (probably to go on another widget or in the taskbar itsef).
As a result, the visualization (that is what’s is improperly called systemtray) now can use much more data than before and can give to the user a representation that makes semantically sense, like showing only “real” notifications in the notification area.
Now the hidden items are a menu, because since an hidden item means it has no notification value, it just have an “interaction” one. so you probably need to access it just to trigger a function, like accessing one of its menu items (that will become a submenu of the main menu) and not anymore.
This design is a radical departure from the previous one (I would go as far as saying that is not a systemtray anymore, or at least that should be the target), so in the current Plasma widget there will be no room for the old behaviour anymore (so no configuration option to make it behave like a totally different widget, that should indeed be shipped as a different widget). However, the modular nature of Plasma, makes it really easy to replace the widget with a different one, maybe derived from the 4.4 branch (that by the way will stay buildable for the whole 4.x lifetime), so if there will be enough demand, rest assured a different widget for your needs will be available somewhere.
Days at Tokamak are running out very quickly: last days we had a very frenetic activity: for me it was spent mostly around adapting aspects of the Netbook Search and Launch interface for touchscreens. It’s impressive how good it looks already with so little changes of code
.
Alongside of that, we are designing a different interface for another different kind of devices: smaller mobile devices, as small as smartphones (hello n900 🙂 or various ways on internet tables.
We have here some N900 and 3 little tablet devices lended by Intel (Compal Jax10 with a Moblin image installed on it actually). I must say the Moblin SDK is quite easy to use, I’m pretty happy with it.
It’s really important for us to actually get going on mobile devices, because with our platform as insanely flexible as it is, we can deliver a really coherent user experience across the board, starting from the desktop, going down to the netbook, to little tablets and cellphones.
Almost entirely different UI, but with an impressive amount of code shared between totally different form factors. That’s the beauty of having a clear separation between the logic and the ui, having a rich framework that helps to keep the ui layer as thin as possible.
We’ll also going to expand theming capabilities by offering the possibility for Plasma themes to offer custom animations…
What does it mean? It will be able to customize the user experience a lot, not only with different desktop themes, but also across different devices, where the interaction patterns and different resource constraints.
It will use of course Javascript, for usual requirements of multiplatform deployment without rebuild and more robustness/security/ease of writing.
In the short term what it means? Expect tasty screencasts in the next few days and new cool shiny toys to play and develop with in the next KDE SC releases.
Arrived yesterday in Nuremberg with the rest of the italian Plasma gang (we wandered half an hour in the -wrong- building in searcch for the hotel reception, quite a surreal experience :p)
Today is the first “real” day, there were a lot of great talks, all of them revolving around our future direction, what’s coming for 4.5 and what’s coming beyond, so expect quite a bit of blog posts about that in those days 😀
I’ve talked abount, surprise surprise, the the Netbook shell 🙂
I’ve talked about some technical details about the various components: what is the different between the Netbook and desktop shells themselved (just the tiny binary), how the search and menu of the Search and Launch interface are done, how is done the new shiny drag and drop, and everything about the newspaper
In brief, for the future, expect a big effort about polishing and bugfixing, to get an experience as smooth as possible (like a cache for the newspaper widgets when the device is offline) and expect some new features, like maybe free resizing of widgets in the newspaper.
