 |
| Tokamak 6 Kaban starting line |
We always set a theme for these meetings so we go in with a goal. We usually spend the first day catching up with the state of the project and each other as well as defining in detail the topics we will cover in the coming days. After the first day's presentations by attendees, we ended up with a wall full of sticky notes arranged in tracks and ready to be marched down towards the finish line.
We organized things into four tracks: the shell, kwin and Wayland, session services and startup and a catch-all miscelaneous track. Unlike some of the past Tokamaks, particularly some of the earlier ones, where we had a very clear and obvious design with implementation gaps that needed filling with code, at this Tokamak the sticky notes on the wall were dominated by design topics.
This really reflects where we are in the development lifecycle of Plasma Workspaces. Currently we have a stable desktop environment with some minor annoyances left to be addressed; bug fixes and user interface cleanups are the norm for development these days when it comes to the desktop shell. This is great for our downstream partners and users as they have a reliable environment to build upon and use.
Simultaneously, over the last year we have also been working on a few very important developments: realizing our device spectrum vision and moving to Qt5 with KDE Frameworks 5.
Single Shell Theory
Many readers of this blog are familiar with Plasma Active which is a Plasma Workspace template for mobile devices; our reference device there has been tablets, but it certainly is not limited to that in any way. This effort which started in 2011, with the first release coming in October of that year, was the next logical step in the plan to build a user interface that spans devices from phones to tablets to media centers to desktops to things we aren't even looking at right now but you might be.In the process of creating Plasma Active (and three subsequent major updates to it) we learned a lot about the power of the Plasma framework and QML. We also learned how it could be better. Sometimes it was simply confirming what we knew needed more work and sometimes it was revelatory. It all came to a head at Tokamak 6 where we took the opportunity to put firm blueprints down on our sketches.
Perhaps the most critical development is the creation of the unified shell. Right now all of the Plasma Workspace share most of their code, but they each carry a separate binary that essentially launches the desktop layer. Bringing together the efforts from desktop, netbook, active and elsewhere, we have developed a single binary that can load any of these shells and which will be able to switch between them at runtime.
The power of this idea was aptly summed up by Marco Martin who wrote, "One interface does not fit any device, but one technology does, especially when it can give you an user interface always optimized for the device you are using in a particular moment." This is an ultimate form of doing more with less and the culmination of some 6 years of effort.
This causes an interesting series of knock-on requirements. First, we need a package that can describe what a given workspace means. What makes up a desktop, what makes a tablet, what makes a netbook? We now have a package definition that includes all custom QML for the shell, the initial setup (done with Javascript, just like it currently is), default settings, processes to ensure are started (and later stopped), window manager tweaks, etc. We are still researching some aspects of this, but a working definition was put down.
This also implies that KWin needs to be able to adjust at runtime. Much of the underpinnings are already there, so this will ultimately be a short hop for KWin. A new KDE daemon plugin (kded module) has been written that tracks what the current shell is along with its runtime attributes (e.g. does it have a mouse, or does it rely purely on touch?) to coordinate this between the different processes.
With a single shell, this also means that all the "helper" interfaces need to follow suit. Things like the lock screen, the logout interface, user switching, the login manager, etc. We've worked hard over the last few releases to make sure that all of these things can now be done in QML. In Plasma Workspaces 2 we will be introducing a new Look and Feel package that can contain QML for all of these components. This means that you can switch, customize and share themes using a single package in a single location on disk. (That's a bit of a simplification as there is a transparent fall-back mechanism, but this is already getting long enough. :)
Qt5, Frameworks 5 and Wayland
Complimenting the single shell approach is the move to Qt5 and KDE Frameworks 5. These are the new releases of the libraries we currently use from the Qt Project and KDE. Thankfully, most of the API has not changed much or at all in these version bumps. Unfortunately, Plasma Workspaces uses two things that have changed a lot: interaction with the windowing system and the QML engine internals. So we've had to pick up our socks and do a lot of work on the internals of the libraries and some of the core apps.
We've actually been able to do quite a lot of this in the Qt4 based versions, so many of you have already seen some of the benefits of this work probably without even being aware of it. After the 4.11 release this summer, however, we plan to shift our focus to pushing out the Qt5 based release.
When will that release happen? We have not discussed it with the KDE release team, nor do we have a firm fix on some aspects of Frameworks 5 so it's too early to commit just yet. We did something equally important, however: we defined what would make this release qualify as being "done" for release.
The principles we agreed to are simple:
- Do not break current workflows; what works now, must work as well or better in the new release
- Stability; it needs to be usable for daily use
- Harmonize all the interface pieces that are now on a common technology footing (QML) but do not reflect that due to disharmony in the visual and interface design
Also part of this move is completing on another multi-year goal we've been working on: being able to support Wayland for the graphics stack and windowing system. We are relying on features in Qt5 for this and KWin has also needed much work to make the transition cleanly, but now it is all coming together. While some seem to be viewing the move away from X11 and x.org as a sprint, we have viewed it as a marathon: a long distance run that you have to plan careful and resolve to finish in the best time you can.
Miscellaneous?
There will also be a number of other small improvements here and there under the hood. For instance, I presented a proof-of-concept rewrite of RunnerManager which is used by KRunner, Plasma Netbook, Kickoff, Home Run and others. The goal is to simplify its threading and thread the things which aren't currently threaded for a zero-interface-thread-blocking design that is also a bit more flexible and which should also be kinder on memory.
Improvements in network management, power management and session startup are also on the table and being worked on.
I highly recommend reading some of the blogs by others who attended this or the parallel Solid sprint to get a further feel for things. That would include Marco's, Martin's, Sebastian's and Lukas' entries.
0 comments:
Post a Comment