After an update by Sebastian K
Resources and Activities
Tag Archives: plasma
Welcome Contour
This is a follow up of another good news that recently appeared on PlanetKDE.
Friday a new project within KDE was announced: Plasma Active. We explained that wasn’t a single project, but more an umbrella of many components, all of them are a piece that we think necessary to reach our goad of a creating a desirable user experience encompassing a spectrum of devices (and remember the date 09.10.11, just saying)
Today we are happy to announce another project that will be a pretty important piece of the puzzle: Contour
The problem
If we want to build a desiderable experience on devices, we have to look around on existing offerings to look not only for what we like, but also for what we don’t like.
What is the common factor of today’s tablet and handheld operating systems?
The center of how they work, are applications, so called apps (why trying to give a new word to a concept at least 40 years old still escapes me btw).
All the tasks that you can accomplish with the device are delegated to a single application (that maybe isn’t enough to do exactly what you want). That’s really a model not much different compared to the desktop one.
Now, having a different entity, with specialized logic and specialized ui to accomplish a particular task is a good thing, but the current problem is the lack of integration among them, especially on the mobile world
On the desktop side, in KDE we are doing pretty good integration wise, can we do as good in the mobile front?
And with integration I don’t mean (only) look and feel. This is important as well as there are also valid use cases to break it in some particular situations.
Contour
This new project is born from the collaboration between several KDE people, the Plasma and Nepomuk project, Basyskom and Open-slx, you can see a first concept video of the new shell here:
Right now I just want to present this user interaction prototype, then we’ll talk more about the actual details behind it, both UI-wise and what is the technology making it possible.
What I’m talking about is all the applications being deeply integrated in the workspace, for certain things there should be rally a central place, from which both workspace and applications could tap:
- What I’m doing right now with my device? (yes, activities again!)
- What kind of resources are now open? (can be files, contacts, urls, whatever)
- What kind of resources are relevant to this activity? (so that i can get very quickly just to them, without having to worry about complex menus and submenus)
- Somewhat related example on the above point: I don’t want 3 apps and the workspace having 4 different concepts and storage for “Bookmarks” for instance.
- What kind of resources could be relevant to this activity? or what actions could be important? (could be publish this photo, answer this email, feed the fish, whatever 🙂
Now, In the last years of development in KDE, we have almost all the needed technology to do all of the mentioned points, just think about Activities, taking a more definite shape in 4.6, resource and ontology storage in Nepomuk, central PIM data storage in Akonadi…
It’s just somewhat harder to do on a desktop since here there are quite a lot of legacy constraints and a long “genetic memory” of the last 30 years that makes really hard for new paradigms to emerge, however I’m sure we’ll gradually get into it there as well 🙂
Mobile systems are still a white canvas where we still can experiment something new, and provided we have most of the technology for it, we’ll be able to have this resource centric, activity based system in a pretty good shape in a really short time.
Plasma Active
So how does it relate to Plasma Active and the current tablet user interface?
Contour is an experimental user interface based on Plasma, that does an heavy usage of Nepomuk and won’t be intended for everyday usage at first, but…
As the rest of KDE and Plasma as well, Contour is designed to be highly modular, so as soon as a part of it gets “ready”, the main Plasma Tablet user interface will immediately adopt it (and eventual other Active workspaces that will surface later).
Reactivate
During last week we spitted out some strange hints about something cool we are preparing. It was been obvious that it had something to do with Plasma and something to do with mobile technologies.
So, here we go with Plasma Active
Active
the active project starts from a simple vision: Create a desirable user experience encompassing a spectrum of devices.
What does it mean? The KDE tecnologies have quite a lot of potential, i think absolutely everywhere, but right nowwe are still mostly targeted on the desktop.
I think that with what we got as platform, is fairly easy, once the last building blocks are there to build both workspaces and applications that can adapt to the whole spectrum of devices computing is today.
An importnant thig comes already in the name: it’s Plasma Active and not Plasma Mobile: why?
What we are doing right now is exactly a mobile project: tablets to be precise, but stopping there would be a mistake.
The Active project is about taking a step further and build applications that have their user interface and implementation completely detached, is about forcing ourselves to not think about a small use case but always about the bigger picture.
Our goal is to be sure that if an application is “certified to be active” can run as well in a tablet, as in an handheld device, as in a set top box, as in a type of device we have completely no idea about, once an user interface module specific for its screen size and input method has been added.
Sounds crazy
But we have the technology, We have QtQuick and Plasma, that combined can provide a single package, that has diffent user interfaces for each supported platform, and the best available interface is chosen from the device. Hopefully the “just right” UI elements will be available, otherwise the best one from a list of preference will be chosen.
Current code
Most of the code for Active is developen in the Plasma mobile repository, with of course all the enhancements needed in the KDE libraries ending up immediately in the usual KDE repos, being immadiately available for the desktop as well.
We don’t only plan to work on the development of the software tough. It’s possible to test the current code from day one, pre packaged, updated continuously.
A bit of clarifications
After Sebas’ blog about it, there was a question on how the various things, Plasma-mobile, Plasma-tablet and the various mobile efforts in KDE relates to each other:
- It’s not a different project compared to plasma-mobile and plasma-tablet
- Plasma mobile and Plasma tablet are actually the same workspace, just a different UI loaded on top of it: that’s the direction we want in both the workspaces and the applications
- It’s an effort to define a good user experience on the mobile, from the distribution all way up to the apps, of which the workspaces are a part of
- Any application, any project is more than welcome to join, bigger the ecosystem is the better it is
- It is now targeted to tablets, this doesn’t exclude phones, set top boxes and washing machines however, that’s the future ;).
Right now it’s available for OpenSuse, later.. who knows 😉
Let’s create the best possible tablet user experience first, then the world 🙂
KDE, what next?
Let me tell you a little story, a story about our vision since a while, a story about what happened the last week, a story about what will happen now and why it will matter for you.
Let’s start with a digression. I started to write this entry several days ago on the bus, from the Milan airport to Turin, after some days in Germany (more on that below) the return in Italy was so typical and so contrasting with the German aim for precision. The highway was closed in three different points, the bus had to take diversions that made the journey some hours longer. Max respect to the driver btw, he managed so well things that were going wrong in an epic way.
But in the end we arrived where we wanted, I decided to not get angry but take the occasion to think and write this lengthy blog entry…
This remembers to me some other story, that wasn’t always easy as well…
Uh, has it something to do with KDE?
14 years ago, the KDE community was born with a very bold vision: give to everybody a cool, attractive, easy to use desktop environment, now we are a worldwide community with hundreds of members, we provide a very strong foundation with the kdelibs framework, many apps, the Plasma Desktop workspace and the Plasma Netbook workspace.
In the end, why we work on the KDE software? Probably everybody has a different answer, in my case i can say, free software, done on top of what i think is the best technology available today is giving to people something that can make their lives slightly better, so the world slightly better as well.
But this to be true it must reach as many people as possible and be really useful on their today’s needs, otherwise it remains just a nice coding exercise.
Every now and then some group feels that a new kind of jump is needed.
- How many expectations we did deliver?
- Do we need something more to be able to be where we want?
- How much the world is changing?
Sometimes in the arc of just one or two years, things are changed so much that you have to question your answers (pun intended?): are the questions still the same?
Many things happened in the last few years since the adventure of the 4th iteration of our platform started (that’s roughly when I joined this strange family: in retrospective I think one of the reasons was that it was one of those “dare to dream” moments).
Some of the things that happened have influenced the future of computing in general (the mobile shift that happening in recent years is only one of them), some others more near to KDE, some things happened were not so good, some were very good.
On the mobile
What didn’t change is my (ours) certainty on the goodness of the KDE platform, even when seemed a weight for some, it’s an amazing toolbox that I know it will be there in the whole device spectrum, giving not only a consistency in look and feel and behavior for the user, but also for the developer.
Some says that the desktop days are over, some says that the desktop world won’t change that much. There is truth in both. desktop is here to stay, there are so much tasks that simply can be done just there (this is confirmed as well by desktop sales going significantly up last year)
But there is as well another truth. often, and for more and more tasks, a more “human”, portable and ergonomic device is way more appealing, smartphones and tablets are an example, and that’s why all our efforts in this direction started.
We have several projects already in the mobile space, like the Plasma mobile workspace, Kontact touch, Marble, Calligra.
Can we do better? Can we have more mobile applications? But most important, can we provide a direction, an unified vision that would make KDE lead and be innovative in the mobile space?
In the end, have an unified, compelling story that would be interesting enough to make KDE the natural choice in the mobile world to both users, and who actually wants to sell a device and has to choose between the various platforms he can ship (and how much freedom he will have when he wants to build a customized, fine tuned experience)
I know what you did last week
Last week some KDE people did met up and started to discuss a bit about those very issues, challenging ourselves and taking a step back to see what we could do to improve our outreach
What we realized is that what is missing is for sure a lot, but on the other hand, we are so near as well.
So expect new entries about it in the near future, we are thinking on it 🙂
Build a device scalable user interface
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.
And a blurry live action video here:
Towards a declarative Plasma: Containments and tablets
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)
A video of a preliminar version can be seen here.
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 😉
Little big cleaning details
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.
You can make the diffrence too 😀
Separed at birth
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.
Good old habits: notifications again
Activities
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 🙂
One plasmoid 3 platforms
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.