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!


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.


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!


Plasma 5.10: Folder View as default desktop mode

Plasma with desktop icons
New defaults: Plasma 5.10 with desktop icons

A brief history lesson

To set the stage, we need to briefly recap some of the problems with the KDE 3.x desktop that (among others) Plasma initially set out to solve.

In the KDE 3.x desktop, three separate applications performed the duties of today's Plasma shell. kicker was in charge of putting panels on screen edges, kdesktop put wallpapers and desktop icons on screens, and SuperKaramba allowed for (quite shakily) putting widget windows in an extra layer between the desktop and application windows. kdesktop was essentially non-extensible (i.e. you couldn't make it put anything other than icons on the desktop by installing an add-on of some kind), while kicker and SuperKaramba could be extended by new plugins at runtime, but using incompatible plugin formats that couldn't share any code and had to do their work using entirely different sets of APIs.

With Plasma 4.0, things got a lot better. Plasma widgets need to be written only once, using one set of APIs, and can then be added to both the desktop and to panels - tuning their UI to their respective surroundings. Moreover, things like the desktop and panels themselves are plugins as well, and can be similarly swapped out (allowing us to make very different UIs for different devices within the same framework). And multiple plugin can share the same data sources in the back, also cutting down on overhead.

Enter Folder View

Folder View is one of the bundled plugins, and it illustrates many of the above concepts. It does what kdesktop used to do - visualize folder contents. But not only can you use it to put icons on the desktop, you can also put additional Folder View widgets on top of that desktop, or put Folder View in your panel, all of them showing different folders. In the panel, it will usually take the form of a button that brings up a popup (which can use either list or icon view modes), but it will expand into the panel itself if the panel is roomy enough, allowing even for a file system sidebar.

No more icons on the desktop?

Back in Plasma 4.0, we made the decision not to use Folder View as the default desktop layout (default being the operative term - users could change this in config, returning to a more traditional icon desktop). Instead, we left the desktop surface empty by default, and had Plasma add a Folder View widget on top of it.

We had reasons for that. We wanted to let users know about Plasma's new abilities: highlight its more modular nature, encourage experimenting with new setups and personalized mix-and-match. We didn't want the desktop to be constrained by the skeuomorphic desktop metaphor that at the time looked like it might well be on the way out (as indicated e.g. by a pervasive shift from spatial to browser-style file management across systems). It was exciting to ponder what things might fill the void left by shedding those icons.

Yes - icons on the desktop

More recent history has shown, however: Icons are here to stay. In mobile, there's been an explosion of new platforms that have really doubled-down on the icons-on-the-homescreen thing, making it more popular than ever. Many of those platforms also mix in widgets as we do, meaning nine years after 4.0, both our long-time and our still to-be-recruited users get all of this with ease now. We no longer need to try so hard when it comes to doing the onboarding for Plasma's key concepts.

The evolved landscape leads us to believe that Folder View is now the better default, and this is what Plasma 5.10 will be shipping (some distributions, of course, have beaten us to this, or have always done so). It will still be possible to have an empty desktop (it's that "Layout" option in the desktop settings), but it's a role-reversal in what's opt-in and what's opt-out. Likewise, extending Plasma with new desktop layouts is of course also still possible.

Better icons on the desktop

Given Plasma 5's incarnation of Folder View is about to be put front and center, we're putting a lot of effort into making it really shine throughout the 5.10 development cycle. Performance has been improved greatly. We've been thoroughly auditing for interaction issues, sorting through feedback and talking to people about how they use Folder View. This has lead to numerous small improvements, often subtle, that improve the feel of using Folder View - e.g. tuning the sizes of various hitboxes and hitpoints to make rectangle selections and dragging icons around that extra bit less cumbersome. Sizes and spacing have been tweaked as well in response user feedback, resulting in a tighter icon grid than before. And there's even some cool new functionality as well.

How you can help

We're committed to making the default experience of Plasma 5.10 - desktop icons included - rock more than ever. If you want to help, several distributions offer live images or packages of current development snapshots. Use them to take a long good look at Folder View, and then let us know about your experience!


Plasma 5.10: Spring-loading in Folder View; performance work

I was sorely remiss not to blog more during the Plasma 5.9 dev cycle. While 5.9 packs a fair amount of nice new features (e.g. here's the widget gallery in Application Dashboard at some point during development), there was not a peep of them on this blog. Let me do better and start early this time! (With 5.9 out today ...)

Folder View: Spring-loading

Spring-loading in Folder View
Spring-loading functionality in Plasma 5.10's Folder View (click for YouTube)

Folder View in Plasma 5.10 will allow you to navigate folders by hovering above them during drag and drop. This is supported in all three modes (desktop layout, desktop widget, panel widget), and pretty damn convenient. It's a well-known feature from Dolphin, of course, and now also supported in Plasma's other major file browsing interface.

Folder View packs a lot of functionality - at some point I should write a tips & tricks blog on some of the lesser known features and how they can improve your workflow.

Performance work in Folder View ... and elsewhere!

But that's not all! I've also been busy performance-auditing the Folder View codebase lately, and was able to extract many savings. Expect massively faster performance scrolling big folders in big Folder View widgets, lower latencies when navigating folders, and greatly improved Plasma startup time when using Folder View widgets on the desktop. In the case of big folder + big widget, a 5.10 Folder View will also use quite a bit less memory.

I've done similar analysis of other applets, e.g. the Task Manager and the Pager, and done both smaller improvements or looked into more fundamental Qt-level issues that need addressing to speed up our UIs further.

Others on the Plasma team have been up to similar work, with many performance improvements - from small to quite large - on their way into our libraries. They improve startup time as well as various latencies when putting bits of UI on the screen.

While it's still very early in the 5.10 cycle, and it won't be shy on features by the end, performance optimization is already emerging as a major theme for that upcoming release. That's likely a sign of Plasma 5's continuing maturation - we're now starting to get around to thoroughly tuning the things we've built and rely on.


Simple Menu launcher on KDE Store

Example screenshot for Simple Menu v1.0
Simple Menu v1.0

Quite a while ago already I wrote a launcher menu widget named Simple Menu. It's using the same backend I wrote for our bundled launchers, and it's a little bit like Application Dashboard scaled down into a small floating window, plus nifty horizontal pagination. It's also really simple and fast.

While some distributions packaged it (e.g. Netrunner Linux), it's never been released properly and released - until now! Starting today, you can find Simple Menu on the KDE Store and install it via Add Widgets... -> Get new widgets in your Plasma.

Please note that Simple Menu requires Plasma v5.9 (to be released tomorrow). Actual v5.9, not the v5.9 Beta - it relies on fixes made after the Beta release.


Ethics in engineering

Powerful: The Code I'm Still Ashamed Of

Things like this are a big reason why I work in open source.


Resurrecting Yakuake

No use in beating around the bush: Yakuake is currently not in great shape. While the codebase made the jump to KDE Frameworks 5 quite early, it took a long time to get releases out, and the latest still suffers from some annoying, if minor, regressions and bugs. The same is also true for outside code Yakuake heavily relies on - namely Konsole, which unfortunately broke some APIs used by Yakuake, including the one used to invoke the "Manage Profiles" dialog. Meh.

Alongside this there's a more fundamental problem, which is that Yakuake's basic UI code has not aged well. There's some nice things to say about Yakuake's theming system, including a stable file format with unbroken backwards compatibility for more than a decade. But that also hints at the fact that it was designed for systems of that era, and for example can't handle scaling to hi-dpi displays at all.

Fortunately I've been able to secure some honest-to-goodness time over the next couple of months address these problems and thoroughly refurbish the Yakuake codebase, dragging it kicking and screaming into the present day. Here's the cliff notes of the todo:

  • New UI/theming system. This is the big one. The new themes will make extensive use of Qt Quick, adopting some familiar patterns from Plasma theming, and using the KPackage framework for packaging and distribution. This will get us scaling support, allow for more flexible UI arrangements (finally single-bar themes that aren't a gross hack, for one), window shadows, and more. Support for legacy themes will be retained via an internal compatibility theme; they will show up in the config dialog as per usual.
  • Fix Konsole breakage. Konsole's embeddable terminal component has been making Yakuake's life harder with bitrot and broken APIs. I'll go in and fix it.
  • Bugfixes. I'll look into addressing the highest-priority bugs that have been reported against the Frameworks 5 version, including the infamous terminal split focus issue.
  • Wayland. Yakuake mostly works on Wayland, but there's some X11-specific code that yet needs to be cleaned up.

Unfortunately out-of-scope for now will be the often-desired support for session restore; this will need a seperate campaign. But the above will ensure that Yakuake stays with us long enough to enable one.

Watch out for a Yakuake 4.0 deserving of the version bump some time later this year. :)


KDE neon Korean Developer Edition (... and future CJK Edition?)

While not being advertised on the KDE neon main page just yet (and it won't be for a while), we've recently begun doing regular builds of a special Korean Edition of neon's Developer Edition tracking the stable branch of KDE's code repositories. The Korean Edition pre-selects the Korean language and locale at boot, packs all the Korean translations we have and comes with a Korean input method pre-setup.

Hangeul metal type from the Joseon era
Joseon-era Hangeul metal type

Why a Korean Edition?

Among many other locations around the planet, the local community in Korea is planning to put on a KDE 20th Anniversary birthday party in Seoul on October 14th. The KDE neon Korean Developer Edition was directly created on request for this event, to be made available to attendees.

That said - this is actually something we've been wanting to do for a while, and it's not just about Korean.

None of the bits that make up the new image are new per-se; KDE has supported Korean for a long time, both with foundational localization engineering and regular maintenance activity. And as of the Plasma 5.6 release, our Input Method Panel is finally bundled with the core desktop code and gets automatically added to the panel on first logon in a locale that typically requires an input method.

Yet it's pretty hard to keep all of this working well, as it requires tight integration and testing across an entire stack, with some parts of the whole living upstream or downstream of For example: After we attempted to make the Plasma panel smarter by making it auto-add the Input Method Panel depending on locale, we couldn't actually be sure it was working as desired by our users, as it takes time for distros to get around to tuning their dependency profiles and for feedback from their users to loop back up to us. It's a very long cycle, with too many opportunities to lose focus or domain knowledge to turnover along the way.

This is where KDE neon comes in: As a fully-integrated product, we can now prove out and demo the intended distro experience there. We can make sure thing stay in working order, even before additional work hits our other distro partners.

Right now, we're kicking things off with Korean Edition, but based on time, interest and testers (please get in touch!), we'd like to build it out into a full CJK Edition, with translations and input support for our Chinese and Japanese users pre-installed as well (as another precursor to this, the decision to switch to Noto Sans CJK as Plasma's default typeface last year was very much made with the global audience in mind as well).

Ok, but where do I get it?

Here! Do keep in mind it's alpha. ☺


Plasma 5.8: Per-screen Pagers

The other day I wrote about the Pager improvements awaiting in Plasma 5.8. In the comments user btin re-raised the issue of limiting the Pager's display to the screen it's currently on, instead of being all-exclusive.

At the time I wasn't sure we could still sneak this in before feature freeze, but thanks to the screen-awareness of the new backend (which, to recap, is shared with the Task Manager and already needs to determine what screen a given window resides on), it turned out to be easy enough to do!

The default remains the screen-spanning behavior for now, but in the Pager's "Display" settings you can now tick a new "Only the current screen" checkbox. If enabled, Pagers in panels on different screens will now nicely be limited to showing their respective screen's windows on each desktop.