JUL
16
2019

Plasma sprint, 2019 edition; personal updates

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.

Alejandro López attaching a silver KDE sticker to my new laptop
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.

Alejandro López attaching a silver KDE sticker to my new laptop
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:

I'm going to Akademy 2019

JAN
2
2019

Join the first KDE e.V. board dinner of 2019

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.

AUG
2
2018

Engineering Plasma: Extensions and stability — Present and future

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 Plasma process architecture diagram
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.

Future R&D Plasma process architecture diagram
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:

I'm going to Akademy promo picture
JAN
24
2018

Off and On Again: The story of KDE Plasma's desktop icons; 5.12 improvements

Desktop icons in Plasma 5.12 LTS Beta
Desktop icons in Plasma 5.12 LTS Beta (Click to enlarge)

Recent news in the Linux desktop community recall an interesting time in Plasma's history: Release 4.1 in 2008, Plasma's second release ever, that time we (in)famously abandoned desktop icons (sneak preview: they came back).

Of course we never really abandoned them. Instead, in 4.1 we initially debuted the Folder View technology, which powers most of the ways to browse file locations on a Plasma desktop. Folder View gives you folder widgets on the desktop, folder popups on your panels - and yes, desktop icons, which always remained a supported option. An option we, crucially, did decide to tick default-off at the time. Instead we chose to place a folder widget on the default desktop, in part to reinforce the then-new widget-oriented ways of doing things in Plasma, things older KDE desktops just couldn't do.

The Awkward Years

A telling sign in hindsight, many distributions reneged on our decision and turned icons on for their users anyway. And yet we had decided to throw the switch upstream; what next?

A period of research and experimentation followed. With all that newly freed-up screen real estate and a new modular architecture, we looked into alternatives for what a device homescreen could be. The PC during this time was in a mood to diversify as well, with new form factors popping up in stores. Some of our experiments took off - the Search and Launch interface we debuted alongside the Plasma Netbook spin in 4.5 directly inspired the popular Application Dashboard fullscreen overlay we introduced in Plasma 5.4. Others, like the Newspaper view, failed to find much of an audience.

Application Dashboard in Plasma 5.12 LTS Beta
The Application Dashboard overlay has its origins in the icons-off adventure (Click to enlarge)

Ultimately, though this period was productive in many ways, we didn't hit upon a clearly-better new homescreen. Elsewhere meanwhile, on a parallel track, the icon homescreen UI metaphor unexpectedly bounced back and grew stronger. Touchscreen handsets introduced a whole new generation of computer users to - essentially - desktop icons. In the following years we saw user numbers and familiarity with homescreen icons increase, not decrease.

The Lights are Back on and the Doors are Open

During the Plasma 5.10 dev cycle, we did a lot of polish work on the desktop icons experience. We then decided that it was time to stop hiding desktop icons support behind a config option: All things considered, the previous default was just not serving the majority of our users well. It had to change.

We still don't place any icons on the desktop by default. (Many distributions do - but they always did for all that time.) Those who enjoy the calm and tranquility of an empty desktop or don't want icons to get in the way of widgets were not impacted by this move. But drop a file or add an app to the desktop, and you now get an icon again, with full support for all of the powerful features KDE's desktops have always offered when dealing in files and links. For the many users who rely on desktop icons, this is a welcome reprieve from having to fiddle around post-install.

Icons of the Future

In the upcoming Plasma 5.12 LTS release, desktop icons are getting even better. We've done a truckload of work on improving the experience with multiple monitors, across which icons can be moved freely again, along with gracefully handling monitor hot plug/unplug. Performance and latency improvements, the key theme to 5.12 in general, have continued where 5.10+ left off, with the desktop reflecting file operations now faster than before.

We've worked though many of the most-reported feature requests and pain points for desktop icons throughout 2017, but we're not done yet. Folder View development continues in 2018 with more outstanding user requests on the horizon, so feel free to get in touch.

Check out the beta now and let us know what else you want out of desktop icons after 5.12!

OCT
24
2017

Community goal: Modern and Global Text Input For Every User

A few months ago, I had the opportunity to give a talk on Input Methods in Plasma 5 at Akademy 2017 in lovely Almería in Spain. If you were interest in my talk but were unable to attend, there's now video (complementary slides) available courtesy of the Akademy conference team. Yay!

A big part of my talk was a long laundry list of issues we need to tackle in Plasma, other KDE software and the wider free desktop ecosystem. It's now time to take the next step and get started.

I've submitted the project under Modern and Global Text Input For Every User as part of the KDE community's new community goals initiative, a new thing we're trying exactly for challenges like this - goals that need community-wide, cross-project collaboration over a longer time period to achieve.

If you're interested in this work, make sure to read the proposal and add yourself at the bottom!

SEP
30
2017

Come dine with the KDE e.V. board in Berlin in October!

As has become tradition in recent years, the KDE e.V. board will have an open dinner alongside its in-person meeting in Berlin, Germany on October 14th, at 7 PM.

We know there will be a lot of cool people in town next month, thanks to a KDE Edu development sprint, Qt World Summit, the GNOME Foundation hackfest and probably other events, and you're all invited to drop by and have a chat with us and amongst yourselves - and enjoy good food.

SEP
5
2017

Konversation 2.x in 2018: New user interface, Matrix support, mobile version

It's time to talk about exciting new things in store for the Konversation project!

Konversation is KDE's chat application for communities. No matter whether someone is a newcomer seeking community, a seasoned participant in one, or a community administrator: our mission is to bring groups of people together, allow them to delight in each other's company, and support their pursuit of shared interests and goals.

One of the communities we monitor for changes to your needs is our own: KDE. Few things make a Konversation hacker happier than journeying to an event like Akademy in Almería, Spain and seeing our app run on many screens all around.

The KDE community has recently made progress defining what it wants out of a chat solution in the near future. To us, those initial results align very strongly with Konversation's mission and display a lot of overlap with the things it does well. However, they also highlight trends where the current generation of Konversation falls short, e.g. support for persistence across network jumps, mobile device support and better media/file handling.

This evolution in KDE's needs matches what we're seeing in other communities we cater to. Recently we've started a new development effort to try and answer those needs.

Enter Konversation 2.x

Konversation 2.x R&D mockup screenshot
Obligatory tantilizing sneak preview (click to enlarge)

Konversation 2.x will be deserving of the version bump, revamping the user interface and bringing the application to new platforms. Here's a rundown of our goals:

  • A more modern, cleaner user interface, built using Qt Quick and KDE's Kirigami technology
    • Adopting a responsive window layout, supporting more varied desktop use cases and putting us on a path towards becoming a desktop/mobile convergent application
    • Scaling to more groups with an improved tab switcher featuring better-integrated notifications and mentions
    • Redesigned and thoroughly cleaned-up settings, including often-requested per-tab settings
    • Richer theming, including a night mode and a small selection of popular chat text layouts for different needs
  • Improved media/file handling, including image sharing, a per-tab media gallery, and link previews
  • A reduced resource footprint, using less memory and battery power
  • Support for the Matrix protocol
  • Supporting a KDE-wide Global and Modern Text Input initiative, in particular for emoji input
  • Versions for Plasma Mobile and Android
  • Updating Konversation's web presence

Let's briefly expand on a few of those:

Kirigami

KDE's Kirigami user interface technology helps developers make applications that run well on both desktop and mobile form factors. While still a young project, too, it's already being put to good use in projects such as Peruse, Calligra Gemini, Gwenview, and others. When we tried it out Kirigami quickly proved useful to us as well. We've been enjoying a great working relationship with the Kirigami team, with code flowing both ways. Check it out!

Design process

To craft the new user interface, we're collaborating with KDE's Visual Design Group. Within the KDE community, the VDG itself is a driver of new requirements for chat applications (as their collaboration workflows differ substantially from coding contributors). We've been combining our experience listening to many years of user feedback with their design chops, and this has lead to an array of design mockups we've been working from so far. This is just the beginning, with many, many details left to hammer out together - we're really grateful for the help! :)

Matrix

Currently we're focused on bringing more of the new UI online, proving it on top of our robust IRC backend. However, Matrix support will come next. While we have no plans to drop support for IRC, we feel the Matrix protocol has emerged as a credible alternative that retains many of IRC's best qualities while better supporting modern needs (and bridging to IRC). We're excited about what it will let us do and want to become your Matrix client of choice next year!

Work done so far

The screenshot shown above is sort of a functional R&D mockup of where we're headed with the new interface. It runs, it chats - more on how to try it out in a moment - but it's quite incomplete, wonky, and in a state of flux. Here's a few more demonstrations and explorations of what it can do:

Repsonsive window layout
Responsive window layout: Front-and-center vs. small-and-in-a-corner (click for smoother HD/YouTube)

Toggling settings mode
Friction-free switching to and from settings mode (click for smoother HD/YouTube

Overlay context sidebar
Overlay context sidebar: Tab settings and media gallery will go here (click to enlarge)

See a gallery with an additional screenshot of the settings mode.

Trying it out

The work is being carried out on the wip/qtquick branch of konversation.git. It needs Qt 5.9 and the master branch of kirigami.git to build and run, respectively. We also have a Flatpak nightly package soon on the way, pending sorting out some dependency issues.

Be sure to check out this wiki page with build and testing instructions. You'll learn how to retrieve either the sources or the Flatpak, as well as a number of command line arguments that are key when test-driving.

Sneak preview of great neat-ness: It's possible to toggle between the old and new Konversation UIs at any time using the F10 key. This makes dogfooding at this early stage much more palatable!

Joining the fun

We're just starting out to use this workboard on KDE's Phabricator instance to track and coordinate tasks. Subscribe and participate! Phabricator is also the platform of choice to submit code contributions.

As noted above, Konversation relies on Kirigami and the VDG. Both projects welcome new contributors. Helping them out helps Konversation!

To chat with us, you can stop by the #konversation and #kde-vdg channels on freenode (using IRC or the Matrix bridge). Hop on and introduce yourself!

Side note: The Kirigami team plans to show up in force at the KDE Randa meeting this fall to hack on things the Konversation team is very much interested in, including expanding support for keyboard navigation in Kirigami UI. Check out the Randa fundraising campaign which e.g. enables KDE to bring more devs along, it's really appreciated!

MAY
19
2017

Join us at Akademy 2017 in Almería!

This July KDE's user and developer community is once again going to come together at Akademy, our largest annual gathering.

I'm going there this year as well, and you'll even be able to catch me on stage giving a talk on Input Methods in Plasma 5. Here's the talk abstract to hopefully whet your appetite:


An overview over the How and Why of Input Methods support (including examples of international writing systems, emoji and word completion) in Plasma on both X11 and Wayland, its current status and challenges, and the work ahead of us.

Text input is the foundational means of human-computer interaction: We configure or systems, program them, and express ourselves through them by writing. Input Methods help us along by converting hardware events into text - complex conversion being a requirement for many international writing systems, new writing systems such as emoji, and at the heart of assistive text technologies such as word completion and spell-checking.

This talk will illustrate the application areas for Input Methods by example, presenting short introductions to several international writing systems as well as emoji input. It will explain why solid Input Methods support is vital to KDE's goal of inclusivity and how Input Methods can make the act of writing easier for all of us.

It will consolidate input from the Input Methods development and user community to provide a detailed overview over the current Input Methods technical architecture and user experience in Plasma, as well as free systems in general. It will dive into existing pain points and present both ongoing work and plans to address them.


This will actually be the first time I'm giving a presentation at Akademy! It's a topic close to my heart, and I hope I can do a decent job conveying a snaphot of all the great and important work people are doing in this area to your eyes and ears.

See you there!

APR
6
2017

Complex text input in Plasma

Binary keyboard
Surprisingly not enough

A brief note: If you're a developer or user of input methods in the free desktop space, or just interested in learning about "How does typing Chinese work anyway?", you might be interested in a discussion we're now having on the plasma-devel mailing list. In my opening mail I've tried to provide a general overview about what input methods are used for, how they work, who they benefit, and what we must do to improve support for them in KDE Plasma.

Bringing high-quality text input to as many language users as possible, as well as surfacing functionality such as Emoji input and word completion in a better way, is something we increasingly care about. With the situation around complex text input on Wayland and specifically KWin still in a state of flux and needing-to-crystallize, we're looking to form closer ties with developers and users in this space. Feel free to chime in on the list or hang out with us in #plasma on freenode.

MAR
10
2017

Fear not, OMG! Ubuntu! You will bounce again!

Serving the quadruped audience

Intrepid journalist Joey Sneddon over at OMG! Ubuntu! recently pointed out to us that Plasma 5 is currently not doing so well when it comes to serving an important user demographic - bored cats!

Indeed, Plasma 5.0 cost them (and us) the Bouncy Ball widget. And the reasoning mentioned in the article ([...] when trying to develop a professional experience toys and gimicks aren’t a good thing to be shipping by default [...]) is actually pretty solid I think. Hmm.

Have we lost our bounce forever? No!

But! These days we have the sexy KDE Store going on, which is a great place to put toys and gimmicks (along with neat menus).

So it's back! Behold the demo:

Bouncy Ball v2.0 on Plasma 5
Bouncy Ball v2.0 on Plasma 5

You can grab it now for your Plasma 5 via Add Widgets... in your desktop menu and then Get new widgets in the Widget Explorer, or check out the Bouncy Ball store page.

Now for some additional fine print, though: I wrote this at ludicrous speed over a Friday night, and it's not well-tested. It behaves a little quirky sometimes (the goal was to match the original closely, but I didn't have a running KDE 4 to refer to). And despite the v2.0 moniker, it's still missing some of the features of the old Ball, including auto-bounce and that satisfying Boing! sound on collisions. I went with v2.0 in honor of the heritage - I'll polish it and add back the missing features a little later!

Update Bouncy Ball v2.1 is now on the store with sound support, auto-bounce, much better mouse response, a configurable simulation tick and a few bugfixes!

Pages