Plasma.next()?

Sebastian wrote a pair of blog entries in the last week about where we are heading with Plasma in the near future. The first was an overview of the pathway to Frameworks 5 and what we're provisionally referring to as Plasma Workspaces 2. The second entry covered his work on making it possible to write widget layouts (aka Containments) in QML.

For me, the key sentence in that entry was this:

The work that is upcoming in Plasma Desktop is further bridging the gap between Plasma’s interfaces for different devices and formfactors.

 I'd like to share a little bit more about what this means long-term, and share a few more nuggets of where we are headed with the various Plasma workspaces in the process.

One Shell To Bind Them

In the early days of Plasma, the idea was to write one binary per form factor and share components between them. This would allow us to sculpt the overall interaction pattern of the shell while sharing the bulk of actual code, particularly the code that took the most effort such as network management. The shells take care of creating and managing the windows that make up the shell: panels, desktop layers, configuration dialogs and controls.

The desktop shell has around 9,300 lines of code, the netbook shell has under 3,000 and plasma-device (used in Plasma Active) has a little under 4000. Given that the rest of the Plasma code base ends up closer to a quarter million lines, this has been a pretty effective strategy.

There a couple limitations here, however. First, you need to write a shell if you want to approach a completely different type of device or interactive pattern. Experience shows that it's only 3-10 thousand lines to do so, but it would be nicer if that number was closer to zero.

Secondly, we've offered the ability for some time to switch at runtime between the Netbook and Desktop form factors. This is a little messy in that we have to stop one process and start the other. Not particularly pretty. With Plasma Active, we also started really fleshing out how much could be done if we also tweaked the settings of the window manager as well as various applications. What we'd far prefer is to be able to change the workspace layout entirely, including the bits that the shells have been doing up until now, without restarting processes and also alter other runtime settings such as changing the window decorations (or even removing them entirely in the case of Plasma Active).

We also learned in Plasma Active that we could write a rather generic shell and populate it entirely with QML. Sebastian's efforts bring those lessons deep into the core of Plasma. So in Plasma Workspaces 2, we want to provide a single shell binary with desktop, netbook, tablet and other form factors all being serviced by it. This will also give us the infrastructure to easily and elegantly switch between interaction concepts, e.g. between a mouse+keyboard-centric Desktop to a touch driven tablet experience. These transitions could be triggered by hardware events (docking, screen connected via HDMI, etc) or user configuration.

The result is that we'll share even more code between the different workspaces, be able to target new form factors even faster and produce a more consistent experience with cutting edge features.

One use case I'm personally looking forward to is plugging my laptop into the T.V. and having Plasma Desktop be replaced with Plasma Mediacenter automatically.

Plasma Framework

In coordination with the efforts to turn KDE's libraries into the highly componentized KDE Frameworks, Plasma's libraries and runtime parts are going to go into their own self-contained repository as well that follows the Frameworks policies. This means that all the components that are currently in kde-runtime will be moving into the same repository as libplasma or into kde-workspace, depending on where they best belong.

This isn't just an exercise in practicing how to use the "mv" command, however. The biggest shift here is that all the user interface bits are going QML. In libplasma2 there is no more QGraphicsView support. While DataEngines, Services, Runners and other data-centric components will continue to be written in C++, Javascript, Ruby or Python, the UI will all be done in QML. This is why we've been porting components at such a pace to QML.

In KDE Workspaces 4.11 we'll have some of the remaining big pieces in place: the window list (tasks) widget, the containments, krunner, etc. So when we make the move to libplasma2 as part of Frameworks 5, we'll be ready for the move away from QGraphicsView and into QML scene graph without hiccups for the user or our development teams. Yes, this means that the next major version of Plasma is going to be somewhat unexciting. We can't promise the fireworks of the 4.0 release, and I'm sure you're all disappointed by that news. ;)

For those who have OpenGL capable hardware and reasonable drivers, this will give them a fully hardware accelerated desktop. In such environments, we'll also have the ability to use fancy things like OpenGL shaders to achieve visual effects and usability concepts we can't do right now.

Oh, and the library is now a fraction of its previous size. More with less.

Plasma Active 5

We're hoping to make Plasma Active 4 the last release based on KDE Platform 4. This is a very important release, if only because it's going to be the version that ships on the Vivaldi tablet. However, we're also looking forward here too.

There are still variables in the equation, but our current goal is to make Plasma Active 5 a slightly longer than usual (for Plasma Active) development cycle and re-base on KDE Frameworks 5. This means Qt 5 and QML Scene Graph. It also means the possibility of using Wayland on devices. The KWin hackers have been insanely busy working on the changes needed to make this possible, doubly so since Martin was recently sponsored to work on KWin full time.

If things go according to plan, we'll be able to use the improved QML shell with libplasma2 and provide a very modern experience in terms of performance and interaction. Things like per-window transformations (important for supporting device rotation, among other things) become within our reach.

We also want to move Plasma Active's code closer to the Plasma Workspaces repositories. In fact, we'd like to create one Workspaces area on projects.kde.org under which the code in kde-workspaces, kdeplasma-addons, the left-overs from kde-runtime/plasma, networkmanagement, bluedevil and new repositories such as kscreen can all come together .. without coming together in one git repository. This will make building everything easier (if you use kdesrc-build, at least) while making it easier for us to manage the various assets.

Of course, it isn't all under the hood work.

Expanding on the Active experience

Something we've striven to do with Plasma Active is create an environment that is productive. Right out of the box you have eBook readers (and books!), office document viewers, a file manager (and even a terminal ;), data sync and much more. Combined with Activities, Plasma Active is really about getting useful things done (where you define what "useful" means) with your device.

We've been working lately on extending that from consumption to production. If you noticed, most of the items in the last paragraph were about using data: viewing, sharing, organizing. What about manipulating and creating? We really would like to make it dead simple to do things like take a photo, touch it up a bit and share it without requiring an Instagram in the way. We'd like to make it as easy to open a spreadsheet and view it as it is to create a new one.

However, in Plasma Active we've made two purposeful decisions: do not expose the hierarchical file system (unless the use case dictates that as a requirement) and do not expose details that are not relevant to the usage of the device (e.g. I care that I can open that spreadsheet, it's less important at that moment that the application is Calligra Sheets). Thus to open a spreadsheet one opens the file manager and goes to Documents, or simply searches for the document from the Launch area directly. No file system, no application launchers.

Creation should be just as straight forward. So we will be providing an interface that focuses on creating new things, just as the Files app focuses on managing existing things. In this model, you will simply tell the device that you'd like to start making a spreadsheet. Oh, and that you'd like to email it to your colleagues when your done.

Combined with an expanded Share Like Connect system and data sync services, publish and subscribe for activities and various other tweaks we have in the pipeline, 2013 will be a really great time for Plasma Active.

The Desktop too!

This will also be a time of significant upgrades to the desktop as well. The QML work is one major thing, but  Share Like Connect will also be featured in the desktop along with improved activity management and widget (Plasmoid) handling.

We have a steady stream of improvements coming starting with 4.10's QML containment support, continuing on to things like kscreen so we have a first-rate hotplug-driven and low-to-no-configuration screen management system (hopefully included with 4.11; many of us are already using it now!) and the bigger UI work that will come with the move to libplasma2 and Frameworks 5.

The desktop changes will not be very radical, but then our focus is to improve performance and expose features like Activities more effectively while also tieing into the multi-form-factor-but-one-shell idea.

Ok, we get it: you're doing lots of stuff.

I could continue to write about what we're up to right now and what that leads to next .. but I fear this is already long enough. I hope, along with Sebastian's and Marco's posts, it gives everyone a slightly clearer idea of where we're heading. We have a lot of work to do to get where we want to go, but we've already accomplished so much in the last few years that we know it is not only possible, but that we have the people who can make it happen.

Of course, one of those people could also be you. :)