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 😀
Those last months have been a lot of hard work in the march towards Plasma Active 1.0, or PA1 in short
Now I can’t already say an exact day and time of the release, but we are sure that’s near, and i mean really near 😉
Every one of you can help making the first release as good as possible, how?
The current pre-release images are downloadable from the usual place, test the hell out of it, it’s fun 🙂
If you find something that is still a bit problematic, you can go to bugs.kde.org, and in the report bug form, there is the “Active” product among the others.
So test it, play with it, have fun and help us to make PA1 as good as possible 🙂
An important part of the Plasma Active Contour user interface is the connection between the objects that i can view with my tablet, like images, webpages, and documents with the current activity, to help to organize your work and fun.
I already wrote here about the activity screen: the main Contour workspace will show everything that is related to the activity and is the natural evolution of the Plasma Desktop activities (that will evolve in this direction as well as the integration with applications becomes deeper;)
The screencast below shows the usage in practiche of the concept I’m going to explain in the next paragraphs: Share Like Connect (SLC).
It also shows towards the end the progress of the Active image viewer application, a touch friendly image viewer that deeply integrates with the Contour UI in terms of Look&feel and technology, since uses Nepomuk as metadata storage backend and supports SLC
So we have an interesting UI problem: easily buildthis relationship between objects and activities with just one click (or so;) without having to navigate trough an over complicated user interface.
So, we have a simply search interface right into the workspace, it works well for many use cases and is really simple, but what if I’m browsing a website and want to add exactly that website in my activity? (or a photo I’m viewing, or a document I’m working on Calligra…)
Copy the url of the website, go to the workspace and paste it somewhere? a bit overkill, isn’t it?
Have some UI in the web browser that lets me add the current site to the activity? Definitely better, but we would end up with a different implementation, and a slightly different UI for each application.. can we avoid that?
We also noticed how similar this problem was to another one: is very common that while I’m viewing something i want to share it with someone in some way: I could want to upload on flickr a photo that I’ve just taken, or I may want to send via email to someone a PDF that I’m reading right now.
On the desktop the current workflow is to leave your current application, go to the web broser or email client, search the file again and upload/send it.
On mobile platforms things looks a bit more convenient: many applications have built in the possibility to share the currently open file to some services, but each application has its own implementation, often having a slightly different ui to do the same thing, or support to different web services, maybe because the developers of the application wanted to push their own services (a random example starting with G comes to mind 😉
So, get back to the problem of connecting the current open “thing” to the current activity (avoiding “file” by purpose, since could be something that is not a file at all, like an URL) is similar to wanting to share this same thing with someone, or rate it, or add a tag, tweet it, like on Facebook…
Since we already log what is the currently open object (for how long, how often etc..) to be able to log history and construct recommendations, the external workspace knows this information.
We can provide actions in a global menu in the top panel to perform those tasks, divided under 3 menus: Share (upload on web services, send by email), Like, (rating, bookmarks, “like” on web services), Connect (connect to the current activity, to an event in the calendar, etc).
Each action is implemented by a plugin, and plugins can be written in both C++ and Javascript, making it possible to download them on the fly from the Web
A first version of this global menu will be available with the first release of Plasma Active, and will eventually make its way to Plasma Desktop as well.
Since MeeGo uses Connman instead of Networkmanager to handle network connections, that means there is not (yet 😉 an user interface to control in right from the KDE workspaces.
If you happen to have one of the Desktop summit Exopc with the Contour user interface that there has been installed on several devices, here are some easy steps to get the MeeGo tablet Connman ui installed and be able to connect to a wireless network.
Ingredients
A device running the Contour MeeGo ui
An USB keyboard
Either an USB ethernet adaptor (preferred) or a thumbdrive
recipe
Open a konsole
vim /etc/zypp/repos.d/ and replace the urls there with http://download.meego.com/MeeGo/snapshots/stable/1.2.0.90/latest/repos/oss/ia32/packages/ (unfortunately repos url changed since the image was built, with newer releases should be smoother)
If you have the ethernet usb adaptor: zypper install meego-ux-settings
If you don’t have it, download from the url above the following files on a thumbdrive:
From the device, as root, rpm -Uvh /media/whatever/*.rpm
After having installed everything on the device, start the settings application with meego-qml-launcher –app meego-ux-settings. After it connects to your access point, it will automatically reconnect on next startup, so no need to launch the settings app again until you want to change access point.
Don’t forget the two getting started IRC session that will be held this week, where we can help on this and other issues
A plasmoid that can manage connections using Connman is planned shortly 😉
