Just a brief heads up. As you know, from now on the recomended way to write plasmoids will be using QML only, and using the new components api for common widgets such as buttons, sliders etc.
What’s cool about this API is that is as compatible as possible with Symbian and Harmattan(N9/N950), so porting to and from those platforms just became a tad easier (That’s especially important in the perspective of Plasma Active).
The documentation of those components just landed on api.kde.org, and can be seen here.
Javascript API describes the global plasmoid object that gives access to plasma specific features
A big thanks to everybody that helped writing the documentation, to Antonis that helped with the script for the generator and Allen that helped with the setup of the infrastructure to api.kde.org 🙂
The rewamp of the KDE Plasma Desktop is continuing: in the 4.8 release it got a completely new QML based device notifier (already quite improved for 4.9), now a new redesign has landed in master, scheduled for the 4.9 release of KDE Plasma Desktop.
The Plasma widget explorer and activity manager have been rewritten from scratch in QML, giving it s much smoother look and feel, new animations for free and what I love most, a way simpler code base.
By replacing the activity manager and widget explorer with the new implementation, over 4000 lines of C++ were removed (traded with around 1000 of much more readable and maintainable QML): this makes it easier to maintain, easier to spot possible problems, easier to modify and experiment new ideas.
With the rewrite of the various components of Plasma Desktop in QML I expect to slash away most of its C++ code base, making the entry level for contributors significantly lower (and being able to finally close long standing bugs 😉
How does it look now?
And the Activity manager: designed to look as coherent as possible with the widgets explorer:
Here showing the inline ui to configure and delete an activity
The overall design is almost the same, but the layout has been redesigned to overcome a problem of the old implementation: it looked quite crowded and dirty, because elements were too cramped together, not very well aligned and sizes were quite eterogeneous. Now we paid a lot of attention about the sizes and positioning of the elements, as shown below, everything is positioned along a quite precise grid, that makes the view look less crowded that it actually is.
I a good trend can be established here, for each release of the KDE Plasma Desktop having some element not only rewritten, but its UI becoming significantly more elegant with few but important improvements in the look or in the behaviour.
One of the priorities in Plasma (desktop and active) is to have a compelling developer story, to make easy, fun and desiderable for people to write plasmoids and actve apps.
The new QML Plasma Components are a big step in this direction, they give a common QML api across devices for a very easy development.
An important part of this is documentation: Api documentation is progressing quite well, but let’s give a little push forward 😉
On the model of the success of the Plasma bug days, let’s have a day on IRC were all interested people can work on them to improve the documentation, have a little getting started tutorial, write wiki pages.
If you are interested on it, please let us know by filling this doodle page.
Today, Plasma Active Two has been released. It has been a pretty hectic 3 months, a very short period that produced anyways a couple of significant architectural enhancements.
Enhancements that are for both users, that will find more nice features and developers, that will find more nice tools for writing new applications and plugins. A way more complete feature tour can be found here. Here are just a couple of things that are quite importnant to me.
Recommendations: organizing items in activities is even easier: you worked for a while on a file or on a website? a simple button to add it to the activity will be present in the left side panel.
New Nepomuk QML bindings: write an application that does complex queries in the semantic database in jjust few lines of QML and JavaScript.
QtComponents: a new widget set to be used in QML applications, that makes very easy porting an application from Harmattan or Symbian.
Bugfixes: we want to make the user experience as smooth as possible 😉
Big props and thanks to everyone that helped out with this release, a group that is growing more and more, from individuals to companies.
One of the biggest new features in Plasma that will be released together KDE Plasma Desktop 4.8 is the new shiny set of QML components, that over the next releases will gradually replace the old simple widgets like pushbuttons lineedits etc.
This is one important step towards a cleaner, easier to use and easier to write user interface, an important step towards Plasma2, where the UI will be completely done in QML, using a fast OpenGL driven scene graph, meaning prettier effects and most important always fast and smooth graphics using more what a modern gpu can actually do.
Here is a video of an example plasmoid (you can find it in the kdeexamples repository, is a good way to learn the api) that shows just a collection of what the available components are.
This is one of the things that are starting to percolate from the work that is being done in Plasma Active and is starting to benefit the desktop as well.
Of course common UI components can’t be really common between the desktop and a mobile device, or between different mobile devices such as tablets and phones, so what about that?
We have a complete series of components targeted to be useful to build widgets for the desktop (as shown in the video above), designed to be as indistinguishable as possible from the old C++ based widgets, so it will mix perfectly in the rest of the desktop. The Device notifier widget is completely rewritten in QML using some of the components for 4.8 and even if it uses 100% new code (modulo the dataengines) it looks and feels exactly the same, there is just a “something” about its smoothness that comes out as a pleasant unexpected thing while it’s used, even if it’s difficult to exactly point the finger at.
So how does the very same widgets gallery plasmoid look when loaded in a Plasma Active two tablet?
The touch specific set of components is used and the plasmoid itself besides using those touch components, adapts itself to the fact of being loaded as a fullscreen application on a tablet and changes its layout accordingly.
Some of those components are pretty universal, especially those without any graphics or input such as Page and PageStack, that manage the life cycle and transitions effect of dynamic pieces of the user interface.
Some components are a bit more specific, but not dramatically different: a button or a text field will look an behave in a very similar way, but for instance we don’t want mouseover effects on a touch screen, and maybe we want the touch area a bit bigger than the actually visible button area for a better grip, but here we still smell at least a partial code sharing.
There are then the ones that we want a flat out different implementation: for instance we want a desktop-themed, independent window for context menus (that is, a QMenu) on the desktop, while we want a more plasma-looking, finger friendly thing on a touchscreen, but still the very same exact api.
We have a series targeted to the current Plasma Active tablet profile uses the 90% of the same code as the desktop version, but everything that needs to be different is different, for instance there we have no mouse over highlight, bigger sizes and hit areas, scrollbars are read only scroll indicators visible only when actually scrolling.
This is just an experiment, a tech demo if you want, but is worth mentioning since it shows how flexible the Plasma scriptengine architecture is. In brief: adding the support of a new language, a new package structure to do widgets and graphics components in some cases takes literally minutes, and then is possible to load this new kind of widgets alongside the existing ones written in c++/qml/javascript/python/whatever.
Now, Plasma supported from the very beginning writing plasmoids using HTML+Javascript, and it allowed in two ways: Mac OSX dashboard widgets or a native style that lets you access the Plasma dataengines and services right within Html and JavaScript.
There is now an effort called WAC to produce a standard-ish package format and api for html widgets and simple apps.
Whether this will go somewhere or not is early to say (just usual wait and see;), but i wondered how hard could it be support loading a package in the wac format and correctly displaying it into a plasma desktop/netbook/tablet session, so this is the result of literally 30 minutes of work 😉 (TicTac toe and the todo thing are example WAC widgets, the rss feed reader is in pure QML)
This can be found in the branch plasma/mart/wac-appletscript of the kde-workspace repo, or can be directly tried built in in the Plasma Active One release (there you go, another reason to try out Plasma Active if there weren’t enough 😉
This is not going in an official near KDE Workspace release since is far from be complete. Namely, it’s lacking the device api, but since is very easy to bind extra objects to QtWebkit, is just matter to sit down and doing it (contributions, as usual are welcome ;).
As said by the title of my last post, one of the things that we are trying to do with Active is “humanizing electrons”… make devices behave how people think instead of making people think like the implementation details behave.
To do that, it is necessary to phase out or better, demote and have in a less prominent way some of the concepts that always been with us, but not because they were good, because for tone technical reason or another 20 years ago we were forced to do this way.
Here we aren’t forced to follow the legacy, and the acquired skills that limit what can be changed on the desktop, on this kind of devices we have almost no legacy. (don’t worry, there won’t be a fresh start in the desktop, only continuous evolutionary changes)
Why I have to care what is a “file” and what it isn’t aren’t pieces of information all the same? i couldn’t care less if a contact or a bookmark are stored in a different way than a pdf.
Why I have to organize my things in a weird tree structure, data type that in the human brain simply doesn’t compute?
Why I see arcane names like /usr, /etc and /dev that are simply pointless in my day to day work?
Why if i subdivide my files by project, a file can’t be in two projects unless i do a copy that will go out of sync?
I want to be able to annotate every thing, to be able to remind me what this is about and why is there (informations that would be unwanted in the file itself tough)
Why if the mail application has informations about a contact, this information is buried in this application and everything else can’t have it?
This list could go on for many more points, but i think the concept is clear: while tools like the filesystem are awesome if well used, but aren’t enough anymore for the amount of data nowdays (yes i know, there will always be people that won’t need this, but this is true for any tool in existence).
In Plasma Active we base our graphical representation as much as possible on activities and on what “things” belong to an activity.
We try to make as less difference as possible between what is a file and what it isn’t.
This was only possible because one of the pillars of KDE: Nepomuk.
Nepomuk provides a metadata storage that is abstract enough to do almost everything you please with it. Everything can be a resource: being files, contacts, urls, places or activities. And everything can be related to everything, and here we have things related to activities, or between themselves (who sent to me this file as attachment?)
Sadly, in the desktop is still not used much, apart some pieces of ui to expose its features here and there (good news, getting better here too), but as Plasma Active shows, if the whole UX has its capabilities as the foundation, it can change the way the device is used in a way that surely wouldn’t be possible without it 😉
Another good news, is that while some pieces of Plasma Active are specific of a device UX, some other parts, like the enhancements to the activity manager are shared with the desktop, so should be easy to expect some of those features, like an UI for connection between resources and activities soon in the desktop as well.
Let me talk briefly about one of the goals we have about Plasma Active, of which today’s release of Active One is just a little baby step in this yet important direction.
We think that looking at different devices as isolated worlds, needing completely different “Apps” and UX stacks for each kind of device it’s pretty limiting, and it’s not the way who uses it (aka “humans”;) thinks.
What we believe in, is that computing devices (doesn’t matter if it’s the laptop, a tablet, or something running in a washing machine) should exist in function of helping the people accomplishing the task they want to do, no more, no less, devices shouldn’t be something complex, hard and therefore “harming”, but should just be extensions of the user harm, of the user mind, just tools, and in every situation, the best tool for the best job.
The line between the devices should be as blurred as possible, what we should target on is the task the user wants to accomplish, a task (or workflow, if we want to use a more trendy term;) a task is composed by many actions, many subtasks, and for each one the perfect tool may or may not be the same device, in the same way that may or may not be the same application.
If I take photos in a vacation I need a camera, when I get back I need a big desktop to view, organize and eventually edit the photos, if I want to quickly view them or show them to my friends, I need the device more appropriate compared to where I am: it could be a mobile phone as small as possible, a tablet if possible, or if we are in the living room, a big flat screen TV.
The need of applications that show a familiar, yet device optimized user interface everywhere becomes evident. why was never really done? just a technical detail missing, now we have it; if used well, QML does an amazing job at that kind of “gapeless” customization.
As evident becomes the needs of perfect synchronization, the need of sending not only files, but metadata and pieces of applications across devices, and the need to have interface as natural and “chromeless” as possible.
That’s one of the goals we’re pursuing with Plasma Active. The KDE community can be a leader in this small revolution, a ground that no one of the other mobile offerings ever adventured into, neither open or proprietary.
Last week has been pretty hectic, i can’t really believe that we are so near to the very first release of Plasma Active.
This is the platform that will be the basis of the pursuit of our vision about the device spectrum, is the platform we will use to build not only a very good user interface for tablets, but to go from there colonizing many other kind of devices.
This has been kind of a mirage for me from the last (two? three already?) years, we are playing with this concept and playing around a workspace for mobile devices since years.. there was plasma-mid, a first prototype designed to run on devices like the venerable n810, that was around 2008.
Then we worked on the first workspace of the KDE project that was not aimed to a strictly traditional desktop machine, KDE Plasma Netbook.
We had to go deeper..
At Tokamak4, we started a new shell, this time oriented towards mobile devices, way more customizable than the previous ones, because it was more heavily based on QML. as a demo state it was made run on cell phones and tablet devices, it learned how to make phone calls, it had many user interfaces looking completely different each other.
Fast forward to the beginning of this year, also thanks to basysKom that seen the potential in it, this shell was improved and merged with a really interesting project: Contour.
It aims to bring some really innovative concept to device UX: deeper use of activities, gathering of usage statistics for useful recommendations (watch out for Plasma Active Two 😉 and in general diminish the importance of the “App” blending all in an uniform seamless “Workflow”.
Plasma Active was born, and became something way bigger than it was expected in the beginning. Bigger than just a tablet interface, that is the “visible” part that will be released tomorrow.
Bigger than just the source code that will be released: it’s a new way to approach to the development of components (not even saying “apps” anymore;) for an user experience composed of more than a single device. It’s the first really fully open stack for devices, bringing an open (as in open process, not only code) system in the closest sector of computing to date.
It’s also the manifest of commitment and reliability of an opensource community: we said over half a year ago that the release was going to be 9/10/11, and 9/10/11 is, showing how serious our intentions are.
What a ride has been, and what a ride will be from here, gonna be fun 😀
