This week, Dan Vratil and me have merged a new feature in KScreen, Plasma’s screen configuration tool. Up until now, when plugging in a new display (a monitor, beamer or TV, for example), Plasma would automatically extend the desktop area to include this screen. In many cases, this is expected behavior, but it’s not necessarily clear to the user what just happened. Perhaps the user would rather want the new screen on the other side of the current, clone the existing screen, switch over to it or perhaps not use it at all at this point.
The new behavior is to now pop up a selection on-screen display (OSD) on the primary screen or laptop panel allowing the user to pick the new configuration and thereby make it clear what’s happening. When the same display hardware is plugged in again at a later point, this configuration is remembered and applied again (no OSD is shown in that case).
Another change-set which we’re about to merge is to pop up the same selection dialog when the user presses the display button which can be found on many laptops. This has been nagging me for quite a while since the display button switched screen configuration but provided very little in the way of visual feedback to the user what’s happening, so it wasn’t very user-friendly. This new feature will be part of Plasma 5.13 to be released in June 2018.
On Monday, KDE’s Plasma team held its traditional kickoff meeting for the new development cycle. We took this opportunity to also look and plan ahead a bit further into the future. In what areas are we lacking, where do we want or need to improve? Where do we want to take Plasma in the next two years?
Our general direction points towards professional use-cases. We want Plasma to be a solid tool, a reliable work-horse that gets out of the way, allowing to get the job done quickly and elegantly. We want it to be faster and of better quality than the competition.
With these big words out there, let’s have a look at some specifics we talked about.
Release schedule until 2018
Our plan is to move from 4 to 3 yearly releases in 2017 and 2018, which we think strikes a nice balance between our pace of development, and stabilization periods around that. Our discussion of the release schedule resulted in the following plan:
Plasma 5.9: 31 January 2017
Plasma 5.10: May 2017
Plasma 5.11: September 2017
Plasma 5.12: December 2017
Plasma 5.13: April 2018
Plasma 5.14 LTS: August 2018
A cautionary note, we can’t know if everything exactly plays out like this, as this schedule, to a degree depends on external factors, such as Qt’s release schedule. Here’s what we intend to do, it is really our “best guess”. Still, this aligns with Qt’s plans, who are also looking at an LTS release in summer 2018. So, what will these upcoming releases bring?
UI and Theming
The Breeze icon theme will see further completion work and refinements in its existing icons details. Icon usage over the whole UI will see more streamlining work as well. We also plan to tweak the Breeze-themed scrollbars a bit, so watch out for changes in that area. A Breeze-themed Firefox theme is planned, as well as more refinement in the widget themes for Qt, GTK, etc.. We do not plan any radical changes in the overall look and feel of our Breeze theme, but will further improve and evolve it, both in its light and dark flavors.
One thing that many of our users are missing is support for a global menu similar to how MacOS displays application menus outside of the app’s window (for example at the top of the screen). We’re currently working on bringing this feature, which was well-supported in Plasma 4 back in Plasma 5, modernized and updated to current standards. This may land as soon as the upcoming 5.9 release, at least for X11.
Better support for customizing the locale (the system which shows things like time, currencies, numbers in the way the user expects them) is on our radar as well. In this area, we lost some features due to the transition to Frameworks 5, or rather QLocale, away from kdelibs’ custom, but sometimes incompatible locale handling classes.
The next releases overall will bring further improvements to our Wayland session. Currently, Plasma’s KWin brings an almost feature-complete Wayland display server, which already works for many use-cases. It hasn’t seen the real-world testing it needs, and it is lacking certain features that our users expect from their X11 session, or new features which we want to offer to support modern hardware better.
We plan to improve multi-screen rendering on Wayland and the input stack in areas such as relative pointers, pointer confinement, touchpad gestures, wacom tablet support, clipboard management (for example, Klipper). X11 dependencies in KWin will be further reduced with the goal to make it possible to start up KWin entirely without hard X11 dependencies.
One new feature which we want to offer in our Wayland session is support for scaling the contents of each output individually, which allows users to use multiple displays with vastly varying pixel densities more seamlessly.
There are also improvements planned around virtual desktops under Wayland, as well as their relation to Plasma’s Activities features. Output configuration as of now is also not complete, and needs more work in the coming months. Some features we plan will also need changes in QtWayland, so there’s some upstream bug-fixing needed, as well.
One thing we’d like to see to improve our users’ experience under Wayland is to have application developers test their apps under Wayland. It happens still a bit too often that an application ends up running into a code-path that makes assumptions that X11 is used as display server protocol. While we can run applications in backwards-compatible XWayland mode, applications can benefit from the better rendering quality under Wayland only when actually using the Wayland protocol. (This is mostly handled transparantly by Qt, but applications do their thing, so unless it’s tested, it will contain bugs.)
Plasma’s Mobile flavor will be further stabilized, and its stack cleaned up, we are further reducing the stack’s footprint without losing important functionality. The recently-released Kirigami framework, which allows developers to create convergent applications that work on both mobile and desktop form-factors, will be adjusted to use the new, more light-weight QtQuick Controls 2. This makes Kirigami a more attractive technology to create powerful, yet lean applications that work across a number of mobile and desktop operating systems, such as Plasma Mobile, Android, iOS, and others.
Planned improvements in our integration of online services are dependency handling for assets installed from the store. This will allow us to support installation of meta-themes directly from the KDE Store. We want to also improve our support for online data storage, prioritizing Free services, but also offer support for proprietary services, such as the GDrive support we recently added to Plasma’s feature-set.
We want to further increase our contributor base. We plan to work towards an easier on-boarding experience, through better documentation, mentoring and communication in general. KDE is recruiting, so if you are looking for a challenging and worthwhile way to work as part of a team, or on your individual project, join our ranks of developers, artists, sysadmins, translators, documentation writers, evangelists, media experts and free culture activists and let us help each other.
Plasma 5.8 will be our first long-term supported release in the Plasma 5 series. We want to make this a release as polished and stable as possible. One area we weren’t quite happy with was our multi-screen user experience. While it works quite well for most of our users, there were a number of problems which made our multi-screen support sub-par.
Let’s take a step back to define what we’re talking about.
Multi-screen support means that connecting more than one screen to your computer. The following use cases give good examples of the scope:
Static workstation A desktop computer with more than one display connected, the desktop typically spans both screens to give more screen real estate.
Docking station A laptop computer that is hooked up to a docking station with additional displays connected. This is a more interesting case, since different configurations may be picked depending on whether the laptop’s lid is closed or not, and how the user switches between displays.
Projector The computer is connected to a projector or TV.
The idea is that the user plugs in or starts up with that configuration, if the user has already configured this hardware combination, this setup is restored. Otherwise, a reasonable guess is done to put the user to a good starting point to fine-tune the setup.
This is the job of KScreen. At a technical level, kscreen consists of three parts:
system settings module This can be reached through system settings
kscreen daemon Run in a background process, this component saves, restores and creates initial screen configurations.
libkscreen This is the library providing the screen setup reading and writing API. It has backends for X11, Wayland, and others that allow to talk to the exact same programming interface, independent of the display server in use.
At an architectural level, this is a sound design: the roles are clearly separated, the low-level bits are suitably abstracted to allow re-use of code, the API presents what matters to the user, implementation details are hidden. Most importantly, aside from a few bugs, it works as expected, and in principle, there’s no reason why it shouldn’t.
So much for the theory. In reality, we’re dealing with a huge amount of complexity. There are hardware events such as suspending, waking up with different configurations, the laptop’s lid may be closed or opened (and when that’s done, we don’t even get an event that it closed, displays come and go, depending on their connection, the same piece of hardware might support completely different resolutions, hardware comes with broken EDID information, display connectors come and go, so do display controllers (crtcs); and on top of all that: the only way we get to know what actually works in reality for the user is the “throw stuff against the wall and observe what sticks” tactic.
This is the fabric of nightmares. Since I prefer to not sleep, but hack at night, I seemed to be the right person to send into this battle. (Coincidentally, I was also “crowned” kscreen maintainer a few months ago, but let’s stick to drama here.)
So, anyway, as I already mentioned in an earlier blog entry, we had some problems restoring configurations. In certain situations, displays weren’t enabled or positioned unreliably, or kscreen failed to restore configurations altogether, making it “forget” settings.
Debugging these issues is not entirely trivial. We need to figure out at which level they happen (for example in our xrandr implementation, in other parts of the library, or in the daemon. We also need to figure out what happens exactly, and when it does. A complex architecture like this brings a number of synchronization problems with it, and these are hard to debug when you have to figure out what exactly goes on across log files. In Plasma 5.8, kscreen will log its activity into one consolidated, categorized and time-stamped log. This rather simple change has already been a huge help in getting to know what’s really going on, and it has helped us identify a number of problems.
A tool which I’ve been working on is kscreen-doctor. On the one hand, I needed a debugging helper tool that can give system information useful for debugging. Perhaps more importantly I know I’d be missing a command-line tool to futz around with screen configurations from the command-line or from scripts as Wayland arrives. kscreen-doctor allows to change the screen configuration at runtime, like this:
Disable the hdmi output, enable the laptop panel and set it to a specific mode
$ kscreen-doctor output.HDMI-2.disable output.eDP-1.mode.1 output.eDP-1.enable
Position the hdmi monitor on the right of the laptop panel
$ kscreen-doctor output.HDMI-2.position.0,1280 output.eDP-1.position.0,0
Please note that kscreen-doctor is quite experimental. It’s a tool that allows to shoot yourself in the foot, so user discretion is advised. If you break things, you get to keep the pieces. I’d like to develop this into a more stable tool in kscreen, but for now: don’t complain if it doesn’t work or eat your hamster.
Another neat testing tool is Wayland. The video wall configuration you see in the screenshot is unfortunately not real hardware I have around here. What I’ve done instead is run a Wayland server with these “virtual displays” connected, which in turn allowed me to reproduce a configuration issue. I’ll spare you the details of what exactly went wrong, but this kind of tricks allows us to reproduce problems with much more hardware than I ever want or need in my office. It doesn’t stop there, I’ve added this hardware configuration to our unit-testing suite, so we can make sure that this case is covered and working in the future.
The Plasma team is meeting in Barcelona, Spain these days to work on the next major version of KDE’s popular workspaces. As we are in a transition period, technically and organisationally, this is a very important meeting. I won’t go into too many details in this post, as they are still being fleshed out, but to give you an idea what we are talking about, here’s a quick run-down of some of the things we talked about.
Process & Transpareny
We do not have firm technical results, we are sharing the proposals we come up with here in the meeting on the Plasma mailinglist for feedback first. This is a change we are making in our development and decision-making process. In the past, we sometimes got the feedback that the Plasma team as a group appears a bit too exclusive to the outside. This stands in contrast to its architectural position. One of the things that make it very interesting to work on Plasma is the scope. This scope is usually work on the workspace UI, and of a specific technology. User interfaces don’t stand on themselves, but they express something and allow access. Examples are hardware integration, where issues like powermanagement, device management, etc. have to be presented in the workspace in a way that first of all makes sense technically, but that also is consistent with the way other “things” are presented, and that is beautiful and engaging with the user, while getting out of the way of doing real work. This is a thin line to walk, and in order to achieve great results, it needs close involvement from all sides.
Related to this is the transparency in decision-making processes. Some people have complained that decisions have been made inside a tight group, and that they don’t feel to be part of this process. This stands in the way of team growth (and no growth means shrinking), making it hard to maintain a high level of quality on the one hand, and on the other hand to improve existing functionality and develop new features. We want to change this. Of course this must not stand in the way of firm direction, but the responsibility has to be shared by more people, meaning that not one person is seen as responsible for more controversial changes, but we as a team stand behind it. This reduces stress on individuals, and leads to a fairer distribution of also the negative sides of responsibility.
Lately, we’ve been struggling with an unwelcoming atmosphere in the Plasma communication channels. We’ve talked about this issue, and everybody present agreed that in order to keep our working environment pleasant, we have to be more friendly and respectful to each other. It’s totally not acceptable to lash out against each other, or to answer emails in condescending ways, to talk to people assuming they’ve bad intentions or anything like that. We need to rebuild some mutual trust, but we also need to step in when things threaten to escalate. As an in-person meeting is a good opportunity to talk about these issues in person, this was an important topic. My personal feeling is that we have reestablished strong standards, and everybody is on the same page and willing to defend this newly found balance. We all share the same goals, and we want our working environment to be friendly and enjoyable, as this forms the baseline for being productive and achieving great results as a team.
Drinking from the firehose
Finally, another topic was the situation of Plasma issues in KDE’s Bugzilla. We have a lot of bugs, and are currently lacking the resources to handle this stream of incoming bugs. We do need to do something about this, since it’s an important tool for support and to increase the quality of our codebase, and in extension the user experience. This means that we will, for the technological transitions deprecate a number of bugs of which we know fairly certainly that they do not apply in Plasma 2 anymore. We’ll also draw clearer boundaries around components supported by the core team (essential functionality), and community-supported addons. This means that we will be able to categorize and prioritize better, and hopefully get a grip on the rather messy situation in our issue tracker. Right now, trying to make sense of the issue reports for Plasma very much feels like this:
On the design side, we’ve started on visual guidelines. This is a tool for us to achieve greater beauty and consistency across the components. Plasma 1 feels, in some places, like a collection of individual, separate components. This is of course true, and it has specifically and purposefully designed like that — it’s a good thing technically, but the architecture should not bleed into the visual appearance. We’ve done a lot of work to ensure visual consistency in our components, and we’d like to take this to the next level. For this reason, we’ve worked on visual design guidelines. We’ve taken the new Plasma calendar as a starting point, since that resonated very well with the community, and with professional designers, and we started to extract guidelines that are commonly applicable also to other parts. This is about usage of fonts, spacing and alignment. On the technical side of this, Digia’s Mitch Curtis, who works on the calendar components in QtQuick Components has joined us for a day of design, planning and hacking, so we have some really nice collaboration going on there as well.
In KDE Plasma 4.6, dass im Januar erscheinen wird, sind so einige Sachen, die den Bereich Hardwaremanagement verbessern. In diesem kurzen Artikel highlighte ich zwei davon: Netzwerk und Powermanagement.
Hier haben die meisten Änderungen unter der Haube stattgefunden. KDE’s Hardware Abstraktionsschicht Solid kommt jetzt gänzlich ohne HAL aus und baut auf die U* Familie, die aus UDev, UPower und UDisks besteht. Eine Änderung in Solid ist, dass jetzt mehrere Backends gleichzeitig ihre Arbeit machen können, was auch notwendig ist, da das monolithische HAL durch die modulareren U* Komponenten ersetzt wurde. Für Applikationsentwickler ändert sich allerdings nichts, alle Solid Funktionen funktionieren nach wie vor, nur benutzen jetzt im Hintergrund einen anderen Mechanismus um ihre Arbeit zu machen.
Eine weitere Änderung hat das Solid Team in mit PowerDevil2 eingeführt. PowerDevil ist ein kleiner Daemon (eigentlich ein Plugin für den KDED) der verschiedene Energiesparfunktionen bereitstellt, wie z.B. das Suspenden der Maschine und Energiesparprofile. PowerDevil2, der in 4.6 neu ist, ist modular aufgebaut und kann mit eigenen Aktionen erweitert werden. So können Benutzer das Verhalten der Energiesparfunktionen komplett selber bestimmen, und sind nicht mehr von hardcodierten Funktionen die mitgeliefert werden abhängig. Diese Action Plugins integrieren sich nahtlos in die Profileinstellungen, wie man auf dem Screenshot sehen kann. Das Batterie Plasmoid, über das auch andere Energieverwaltungsfunktionen, wie z.B. Suspend und Hibernate verfügbar sind glänzt im 4.6 Releasezyklus vor allem durch Bugfixes. So habe ich diese Woche noch 4 Patches, die Aurelien bereits in den Trunk Zweig eingeplegt hatte auf das bereits abgezweigte 4.6 Branch zurückportiert.
Für 4.7 plane ich, erweiterte Informationen über den Energieverbrauch und Zustand der Akku(s) hinzuzufügen, ich habe mit der Entwicklung davon bereits begonnen. Dazu allerdings mehr zu einem späteren Zeitpunkt, jetzt liegt erstmal der Fokus auf Plasma 4.6, und danach darauf, das openSUSE 11.4 Release rund zu gestalten.
openSUSE liefert im 11.4 Release, das auf KDE 4.6 aufbaut das neue Netzwerk Management Widget mit, ein Plasmoid dass es erlaubt Netzwerkverbindungen aufzubauen. Im Hintergrund baut es dabei auf den bekannten NetworkManager auf. Um die Jahreswende sind hier vor allem noch VPN Funktionen hinzugekommen, dank einiger freundlicher Entwickler, die mir Patches zusandten. (Ich selber benutze kein VPN, bin daher auch auf die Mitarbeit anderer angewiesen.) Ansonsten unterstützt das neue Applet Wifi und Ethernetverbindungen sehr gut, ist aber auch für’s mobile Internet bereits gerüstet. Die Integration des Modemmanagers ist bereits weit fortgeschritten, und sollte funktionieren. (Auch hier kann ich’s nicht selber testen, falls es hakt bitte Bugreports einstellen. Wer drahtlose Netzwerke benutzt, die ihre SSID nicht broadcasten, d.h. die "unsichtbar" sind, hat im Moment leider noch Pech, die Unterstützung für diese Netzwerke ist noch nicht komplett. Man kann sich aber behelfen, indem man (als root) "iwlist wlan0 scanning essid <MYSSID>" ausführt. Danach ist das Netzwerk in Plasma sichtbar, und man kann sich damit verbinden. (Dieser Vorgang ist nur einmal nötig, da das Netz nun in Zukunft direkt erkannt wird.) Visuell bin ich mit dem Netzwerkeinstellungsplasmoid schon recht zufrieden, d.h. im Grossen und Ganzen tut es das, was es sollte. Es gibt noch einige Sachen, die ich kurzfristig beheben möchte, so kann es vorkommen, dass die Liste auf der rechten Seite leer ist, d.h. keine vorkonfigurierten Verbindungen zur Verfügung stehen. In dem Falle sollte man drahtlose Netzwerke in der Nähe sehen. Meinerseits liegt der Fokus hier also vor allem auf Polishing und Bugfixing, sodass es nicht nur cool aussieht, sondern auch so reibungslos und unauffällig wie möglich funktioniert. Es sind allerdings auch nette Features wie Unterstützungen für "system connections", die dann auch aktiv bleiben, wenn man ausloggt.
Sleep deprived as I am, I figured I’d do something more visual than my usual wall of text (quoting TGEN: "tl;dr", or for the markeys and others blessed with attention deficits, like me right now after a bunch of really intensive days :-)). So here goes the Solid Photo Blog, fresh from Madrid:
Alex Fiestas (Ale-Ale-Jandroooo), BlueDevil hacker, UFOCoder and kind host of the Solid bunch.
Categorizer, Bluetooth hacker, new KDE-UDev maintainer and KDE-ES Vice president Rafael "ereslibre" Fernando Lopez. UFOCoder and kind host.
Kevin "ervin" Ottens: Solid Maintainer, Sprint Kanban Manager and my pillow-talk mate for the sprint (I spare you the details, but notice the ghost behind ervin).
The cutest youngest aspirant Solid hacker, branched off in Nuremberg.
Mandatory group photo, top-left to bottom-right: Dario Freddi (PowerDevil), Will Stephenson (Network Management, openSUSE), Kevin Ottens (Solid Maintainer, KDE Mobile platform dude), Lamarque Souza (Network Management mobile broadband dude), Javier Llorente (openSUSE dude), Alex Fiestas (Bluedevil, upower backend), Rafael "ereslibre" Fernando Lopez (KCategorizedItemView, BueDevil), Albert ‘tsdgeos’ Astrals Cid (KDE-ES presidente, localization expert), Sebastian Kügler (Power & Network Management (Plasma) chrome, KDE e.V. dude, me, myself and I). Background: Our Kanban-based workflow, containing tasks for internal communication and progress-tracking.
Agustin Benito Bethencourt, Gran Canaria Desktop Summit organizer, ASOLIF contact and generally nice ‘high-level-thinking’ dude. (Missing in the group-photo.)
Madrid’s Gran Via, early morning.
Clearly a Power Devil.
Solid Kanban Wall, the tasks being worked on on sticky notes.
It’s a hacker, and it runs on water, man. ON WATER, MAAAN! (But not exclusively.)
I’ve also uploaded these photos (and a bunch of others) to my FlickR pages, if you’re looking for the full-size versions or more photos, get them over there.