Over at Akademy 2020, I just witnessed a fantastic talk by KDE contributor mainstay Kévin Ottens on "Lost Knowledge in KDE". In the presentation, Kévin showed us a series of examples of sophisticated solutions to important problems KDE has innovated and implemented over the years - and subsequently lost knowledge of, applying them sparingly or inconsistently, or developing new solutions redundantly. He also talked about how this is a familiar problem to organizations, with a research field known as knowledge management itself looking to develop solutions and tools to combat this problem since the late 20st century.

He also highlighted how we don't use comm tools with higher knowledge retention factors - blogs, mailing lists, media with more permanent discussion records - as much anymore. So here's a suggestion in blog form! :-)

Within the wider open source as community as well as industry, the idea of writing Architecture Decision Records has recently become quite popular. ADRs are not really a new tool - surely forms of it have been around for a long time in various organizations - but giving the renaissance of the concept a name has a lead to ample discourse on its pros an cons, and plenty of resources available.

To give my take, an ADR is a concise write-up of a particular project/community decision. It should have enough detail to make the decision understandable, as well as cover its context and implications. They usually have an owner and co-authors, and are finalized via a light peer-review process. It's a bit like drafting and finalizing a PEP, another popular tool - except instead of motivating a change, it is describing a decision, to serve as a cache and make sure future discussions and changes have a frame of reference to work with. In this sense, it's a bit like KDE Manifesto, which has served us rather well.

ADR's aren't perfect - they can't and shouldn't replace other forms of documentation, such as API docs and protocol specs. They also have a problem with indexing - while being able to refer to/link to a particular ADR is extremely useful when someone is aware of the relevant ADR already, they're little information silos that are hard to dive into in flat-list format. But the big pro is that they have a low barrier of entry due to the lower effort and process overhead required compared to other forms of documentation, if implemented well. They make it more likely for documentation to be written.

KDE's design community has recently started making use of this idea, writing down some decisions that otherwise had a tendency to be re-discussed again and again: Design Lessons Learned.

I think we could co-opt the ADR idea and apply it to a lot of the examples Kévin showed, to record the needs and thinking that lead to building various solutions and frameworks we have: What problem were we trying to solve? Why was it better than we had before? How does the minimum bar look like now that we have the solution? Where should the solution be applied without fail? What alternatives were discussed and discarded before making the solution?

All we'd need to get started is a wiki space, a good ADR template, a minimal kdereview-like process, and a few good examples to seed the list ...

We (as a UI shell project) see the limits of our territory as the window, when there is the assumption nowadays that MDI tabbed interfaces are where most significant user activity takes place. Yet interacting with different views/documents within those windows is not standardised, so the user has to remember which app they are using, then select the appropriate actions to:

Following Volker's last blog on this topic, here are some highlights of the recent work that has been done around Kontact / PIM during this summer. First of all, stats: there were around 1200 commits in the past two months, leading to the new 19.08 release.

KDE Itinerary

You can have a good overview of Volker's work by following this blog.

Kontact

It seems our team was mostly focused on cleaning, fixing and introducing little UI features during summer:

Today I'm in beautiful Milano, Italy, where the KDE community has gathered for its annual user and developer conference, Akademy. At Akademy I've had an opportunity to present my new KDE project to a larger audience: A ground control application for drones, Kirogi.

Kirogi's direct flight controls screen

Kirogi aims to enable the operation of drones of all sorts of makes and models in an approachable and polished manner, with both direct and map-based control modes and many more features planned for the future.

The origin story behind the Kirogi project is a classic open source tale. During this year's Lunar New Year holiday, I was paying a visit to family in Busan, South Korea (the name Kirogi is Korean and means wild goose). During the off-days I ended up buying my first drone. I attempted the first flight in my mother-in-law's living room. Unfortunately the official vendor application immediately started crashing after take off - much to my embarassment, I couldn't land the thing! Eventually it slowly drifted towards a very nice armchair (sorry mom!) and crashed on contact with an emergency engines-off.

Turns out the app I was using had been replaced by a newer, seperate app store upload intended for a newer drone - and the app I had wasn't fully compatible with a newer version of the phone's OS anymore. I realized open source can serve drone owners better there and started hacking on this new KDE application a few days later.

Since then I've received a lot of support and help from many people in the fantastic KDE community, including Krita-powered artist L. 'AsmoArael' C., who responded to a request I posted KDE's Artists Wanted forum and helped me realize Kirogi's mascot:

Kirogi's mascot, a farm goose and technology enthusiast

If you want to know more about the project's origins and dive further into the technical details, I invite you to check out the slides for the talk I gave today. It was recorded on video as well; I will add a link once it's been made available.

The project also has a website already. Along with much additional information on the project it features download links for nightly development builds.

In June, I had a great time at a series of KDE events held in the offices of Slimbook, makers of fantastic Neon-powered laptops, at the outskirts of Valencia, Spain. Following on from a two-day KDE e.V. board of directors meeting, the main event was the 2019 edition of the Plasma development sprint. The location proved to be quite ideal for everything. Slimbook graciously provided us with two lovely adjacent meeting rooms for Plasma and the co-located KDE Usability & Productivity sprint, allowing the groups to mix and seperate as our topics demanded - a well-conceived spatial analog for the tight relationship and overlap between the two.

The Plasma team walked the gorgeous Jardí del Túria almost every day during their sprint week to stay healthy and happy devs.

As always during a Plasma sprint, we used this opportunity to lock down a number of important development decisions. Release schedules, coordinating the next push on Plasma/Wayland and a new stab at improving the desktop configuration experience stand out to me, but as the Dot post does a fine job providing the general rundown, I'll focus on decisions made for the Task Manager widgets I maintain.

On one of the sprint mornings, I lead a little group session to discuss some of the outstanding high-level problems with the two widgets (the regular Task Manager and the Icons-only Task Manager), driven by frequent user reports:

• Poor experience performing window management on groups of windows
• Unnecessary duplication in the UI displaying window group contents
• Unintuitive behavior differences between the two widgets

To address these, we came up with a list of action items to iteratively improve the situation. Individually they're quite minor, but there are many of them, and they will add up to smooth out the user experience considerably. In particular, we'll combine the currently two UIs showing window group contents (the tooltip and the popup dialog) into just one, and we'll make a new code path to cycle through windows in a group in most recently used order on left click the new default. The sprint notes have more details.

Decision-making aside, a personal highlight for me was a live demo of Marco Martin's new desktop widget management implementation. Not only does it look like a joy to use, it also improves the software architecture of Plasma's home screen management in a way that will help Plasma Mobile and other use cases equally. Check out his blog post for more.

I got a new laptop. Slimbook founder Alejandro López made it a proper computer by attaching a particularly swanky metal KDE sticker during the preceding KDE e.V. board sprint.

In KDE e.V. news, briefly we stole one of the sprint rooms for a convenient gathering of most of our Financial Working Group, reviewing the implementation of the annual budget plan of the organization. We also had a chance to work with the Usability goal crew (have you heard about KDE goals yet?) on a plan for the use of their remaining budget -- it's going to be exciting.

As a closing note, it was fantastic to see many new faces at this year's sprint. It's hard to believe for how many attendees it was their first KDE sprint ever, as it couldn't have been more comfortable to have them on board. It's great to see our team grow.

See you next sprint. :)

In more personal news, after just over seven years at the company I'm leaving Blue Systems GmbH at the end of July. It's been a truly fantastic time working every day with some of the finest human beings and hackers. The team there will go on to do great things for KDE and personal computing as a whole, and I'm glad we will keep contributing together to Plasma and other projects we share interests and individual responsibilities in.

As a result, the next ~10 weeks will see me very busy moving continents from Seoul back to my original home town of Berlin, where I'll be starting on a new adventure in October. More on that later (it's quite exciting), but my work on the KDE e.V. board of directors or general presence in the KDE community won't be affected.

That said -- between the physical and career moves, board work and personal preparations for Akademy, I'll probably need to be somewhat less involved and harder to reach in the various project trenches during this quarter. Sorry for that, and do poke hard if you need me to pick up something I've missed.

And of course:

Like every year, a number of KDE PIM developers met in Toulouse for a bit of bugfixing.

Dirk Hohndel talked about his experiences with QML and Kirigami at LCA 2019:
Producing an application for both desktop and mobile

I think that's quite useful for us as feedback from somebody who is not directly part of the KDE community.

Yesterday KEXI 3.2 Beta shipped, effect of improvements from entire 2018. Full info in the wiki.

That's best KEXI to date! Pun intended because among other things one is especially worth mentioning, entirely new and final date/time grammar for user's SQL.

Twice a year (on that note, happy new one!), the KDE e.V. board of directors comes together for an in-person meeting, taking care of business. It's become a tradition that on one of the two meeting days, the board hosts a dinner event open to KDE users, contributors and other interested parties.

The board's first meeting of 2019 will be in Seoul, South Korea, and the dinner will be held on Saturday, January 19th in central Seoul.

If you're interested in attending (us five board members aside, we've already had the pleasure of confirming the attendance of many notable local community members - it won't be boring!) and talking all things KDE and FOSS over good food with us, please drop me a mail. Modulo available space, I'll get back to you with details on the time and location as soon as we've finalized both.

This week, we have received a number of inquiries into how Plasma extensions, particularly those found on the KDE Store, relate to the stability and safety of a Plasma system. With an engineering focus, this blog hopes to provide answers.

Crash Resilience By Process Isolation

Present-day process architecture: Compositor and shell UI are isolated from each other

In Plasma, the shell UI and the compositor are isolated into seperate processes (plasmashell and kwin, respectively). The two exchange information regulated by IPC mechanisms such as the windowing system (Wayland or X11) and DBus, using standard protocols where suitable and custom-created ones where needed.

In a Wayland session, it's kwin that plays host to your application clients and puts them on screen (on X11, both KWin and app are clients to the X Server, providing a further isolation - KWin can crash and restart without impacting apps). Shell UI extension live in the seperate plasmashell process.

In the event that a shell extension crashes the shell, this allows it to be restarted without impacting KWin and therefore without impacting your applications. They continue to run undeterred while the shell takes steps to right itself.

Beyond crash resilience, putting limits on untrusted code run in the compositor process also has a security dimension. Particularly on Wayland, where one of the design goals is not to allow untrusted code to introspect the windowing system globally.

Meanwhile, to make KWin ready to taking over for the X Server in a Wayland session, we significantly upgraded our engineering story - requiring and dramatically raising unit test coverage for KWin and related library code, for one.

Process Isolation: Next Steps

The architecture discussed above shields applications and the compositor from shell UI extensions, but it doesn't shield the shell. We want to fix that next.

Next: Isolate shell UI and extensions, too — individual or batch processes for extensions

The always-stunning David Edmundson has been spearheading several engineering efforts to make the shell itself have a multi-process architecture. Some of this has already quietly been shipping in the Plasma 5.12 LTS release: KRunner plugins, which provide search results in our menus/launchers, can now opt into running out-of-process. We've used this to isolate some of the crash chart-topping plugins, preventing them from taking down the shell when performing a search query.

Likewise, for shell UI extensions, he has been working on top off the library stack we initially built for the Wayland transition to allow them to be run out of process and then get composited into the shell UI. In addition to making the shell far more resilient to extension crashes, this would also create additional security domains for untrusted extension code - we can build on this to sandbox and drop privileges for them.

All of this is broadly similar to application architecture improvements pioneered by multi-process web browsers in past years, albeit built squarely to leverage the shared free desktop stack (particularly Wayland and DBus). Unlike what took place in Firefox' project Electrolysis, however, we don't see a need to break extension compatibility in our case. For Plasma's extension API scope, we've always taken a conservative demand-based approach instead of allowing extensions free access to all data and code by default. This is paying dividends now, allowing us new shell architecture options while preserving the known, stable API contract it has with its extensions.

David is set to show off the R&D proof of concept we have working now in his talk at this year's Akademy conference, which I can't wait to attend. Be sure to also keep your eyes peeled on his blog, where he will dive deeper into the details of this project after the conference excitement.

In Summary

Plasma today is architected to prevent shell UI extensions from being able to crash your session and interfere with your apps. We are working to expand on this and prevent extensions from interfering with the shell.

In Context

One of the broad goals of Plasma 5 has been raising quality. This is a user-driven process. Converting feedback we got during the first generation of Plasma into software, we worked hard to bring Plasma users tangible improvements to speed, resource usage and UI polish (this is by no means over, either). We also already implemented a LTS release process to improve our support story.

Dove-tailing with the KDE community's Goals, climbing higher on the ladder of safety and security is one of our immediate next ones. Increasing process isolation in Plasma and achieving state of the art crash resilience and sandboxing, a likely first on the desktop, is a concrete engineering expression of this aim.

Sounds interesting? If you want to be part of a team and a community that keeps pushing the desktop (and not just the desktop) forward in the days to come, join us in one of our channels.

Of course: