Updates on Kate's Rust plugin, syntax highlighting and the Rust source MIME type

The other day I introduced a new Rust code completion plugin for Kate, powered by Phil Dawes' nifty Racer. Since then there's been a whole bunch of additional developments!

New location

Originally in a scratch repo of mine, the plugin has now moved into the Kate repository. That means the next Kate release will come with a Rust code completion plugin out of the box! (Though you'll still need to grab Racer yourself, at least until it finds its way into distributions.)

For now the plugin still works fine with the stable release of Kate, so if you don't want to build all of Kate from git, it's enough to run make install in addons/rustcompletion in your Kate build directory.

This also means the plugin is now on - product kate, component plugin-rustcompletion (handy pre-filled form link). And you can submit patches via ReviewBoard now.

New feature: Go to Definition

In addition to code completion popups, the plugin now also installs Go to Definition action (in the Edit menu, the context menu, and you can configure a keyboard shortcut for it as well). It will open the document containing the definition if needed, activate its view and place the cursor at the start of the definition.

Rust syntax highlighting now bundled with Frameworks

After brainstorming with upstream, we decided together that it's best for Rust and Kate users to deprecate the old rust-lang/kate-config repository and move the syntax highlighting file into KDE's KTextEditor library (the foundation of Kate, KDevelop and several other apps) for good, where it now resides among the many other rules files. With 1.0 out the door, Rust is now stable enough that delivering the highlighting rules via distro packages becomes feasible and compelling, and moving the development location avoids having to sync multiple copies of the file.

The full contribution history of the original repo has been replayed into ktexteditor.git, preserving the record of the Rust community's work. The license remains unchanged (MIT), and external contributions remain easy via ReviewBoard or

KTextEditor is a part of KDE's Frameworks library set. The Frameworks do monthly maintenance releases, so keeping up with the Rust release cadence will be easy, should the rules need to be amended.

It's a MIME type: text/rust

Kate plugins and syntax highlighting files preferably establish document identity by MIME type, as do many other Linux desktop applications. The desktop community therefore maintains a common database in the shared-mine-info project. With the inclusion of a patch of mine on May 18th, shared-mime-info now recognizes the text/rust type for files matching a *.rs glob pattern.

If you're searching, opening or serving Rust source files, you should be using text/rust from now on.

That's it for today! I still have a bunch of improvements to the plugin planned, so stay tuned for future updates.


Basic code completion for Rust in KDE's Kate (and later KDevelop)

A few days ago the Rust community announced v1.0 of their new systems programming language, Rust. Having followed the project for some time and finally having used the language for a number of small projects this year, I've come to feel that using Rust is interesting, fun and productive. I'd like to highly encourage everyone to give it a look now that it's finally considered ready for prime time.

To aid the effort I've put some Sunday hacking time into a basic Rust code completion plugin for Kate today. It's built around Phil Dawes' very nifty Racer, freeing it up to concern itself only with exposing some configuration and getting data provided by Racer into Kate. Not difficult at all.

This is what it looks like in action:

The Rust code completion plugin for Kate


The plugin is very basic at the time of writing (which is minutes after getting things working, this Sunday is running out!). The mapping of completion match metadata to Kate's format (from fundamentals like the match type, to more complex features like smart grouping) can likely be improved still. Ditto for auto-completion behavior (i.e. defining the circumstances in which the completion popup will kick in automatically, as opposed to waiting for manual invocation) and simply performance.

The plugin also doesn't work in KDevelop 5 yet, although that one's on KDevelop -- it doesn't support the KTextEditor plugin type present in Frameworks 5 yet. I'm told the KDevelop team has addressing this on their agenda.

Syntax highlighting

Both KDE and Rust implement the AwesomeCommunity trait. The Rust community in particular maintains an official Kate syntax highlighting file here. The repository for the Kate plugin includes this as a submodule and installs it by default; if you'd like it not to do that, there's a build system toggle to disable it. Update: With the move of the plugin source (see below), this is currently no longer the case, but the upstream repo now has install instructions!

A MIME type for Rust source code

While the plugin will run for all *.rs files, Kate/KDevelop plugins and syntax highlighting files preferably identify documents by their MIME type. It turns out there isn't a MIME type for Rust source code in shared-mime-info yet, so I've started the process of getting one in. (Update: Merged, along with this and this!)

Getting the plugin

The plugin is currently still hosted in a personal scratch repo of mine, on You can browse the source , or skip straight to this clone URL:


This location might change if/when the plugin is promoted to proper project status; I'll update the post should that happen. I've included some install instructions that go over requirements, options and configuration. Note that you need a Rust source tree to get this working. Check them out!

Update: As of May 20th 2015, the plugin is now bundled with Kate in its repository (browse), to be included in the next Kate release. You can get it by building Kate from git as whole, or you can do make install in just the plugin's subdir of your build dir; at this time it works fine with Kate's last stable release. Given all this, I'll only quickly recap some additional info for getting it working here: Once you've enabled the Rust code completion item in the plugin page, a new page will appear in your Kate config dialog. Within are config knobs for the command to run Racer (which you'll therefore need an install of) and the path to a Rust source tree (which you can of course grab here), which Racer needs to do its job. Make sure both are set correctly, and then start editing!

Getting in touch

If you have any comments or requests and the blog won't do (say, you have a cool patch for me), you can find my mail address inside the AUTHORS file included in the repository. Signing up for's proper bug tracking and patch submission pathways is still pending :-). Update: After the move to Kate's repository (see above), you can now file bugs and wishes against the plugin via the plugin-rustcompletion component of the kate product on our bugtracker (handy pre-filled form link). You can also submit patches via ReviewBoard now.


Moving desktop widgets without the handle

Moving a widget in Plasma Desktop 5.3 in press-and-hold mode
Getting a move on (notice the mouse pointer)

In Plasma Desktop 5.3 (released today), the desktop configuration dialog offers a new experimental tweak: A mode in which widgets can be dragged around by pressing and holding anywhere on the widget. When enabled, the widget handle is also no longer shown just on hover, but only after a press and hold.

The goal of this mode is to make widget handling feel more natural and spatial, and faster. Instead of having to aim for a widget to reveal the handle, and then go after the handle in a second step, you can just grab on to it anywhere. Easy.

The immediate challenge with this setup is discoverability. To address this problem, unlocking widgets in this mode displays a notification bubble introducing the interaction pattern (which can be easily dismissed forever with the action button):

Press-and-hold notification bubble on widget unlock
"It looks like you're moving a widget"

Press-and-hold widget handling is not yet the default in 5.3 (you can enable it on the Tweaks config page of both the Desktop and Folder View containments). Beta feedback has been positive so far, but changes to the interaction vocab of our shell components shan't be done lightly—using press-and-hold for widget handling means withholding the verb from widgets themselves, which is something we have to negotiate with widget authors. We think the joy felt when using this pattern and its widespread adoption in other home screen UIs bode well for it, however. Let us know how you feel!


Building on new pillars: Activities and KPeople in Plasma 5.3

With the release of Plasma 5.3 only days away, it's time to start talking about some of the new features users of Plasma Desktop will get their hands on in the new version.


Many Plasma Desktop users are already familiar with Activities as a toolbox to divide and organize their personal computing environment into shards: You can set up and name activities, distribute application windows across them, associate relevant files with them, switch between, start and stop them to your heart's content.

A previously less explored side to the Activities story is what the technology can offer while working inside any one of your activities - thus even if you don't bother with setting up more than one and just stick to the default activity created for you the first time you log into Plasma.

This changes with Plasma 5.3! New work to make it easier for applications to enter useful data into the activity's knowledge store, as well as run smart queries against it, enable some new and improved functionality in both the Application Menu and Task Manager widgets in this release.

In Application Menu, all of the Recent categories (one of which is new) are now powered by Activities. One immediate advantage of this is that their contents now change with the activity you're in, but as promised it also provides several other inherent benefits:

The three Recent categories in Application Menu 5.3
The three Recent categories in Application Menu 5.3

  • Recent Applications used to be only aware of applications launched through Application Menu itself. With launch info now retrieved from the Activities knowledge store and all other launchers (for example KRunner, but also just opening a document from Dolphin is a launch) free to enter data there, this submenu can now gather much more recent system activity in one place. Furthermore, new data sources can be added as time goes on without having to touch Application Menu itself.
  • Recent Documents benefits in a similar way. Over the older KRecentDocument framework used before, the Activities backend offers access to a longer, richer backlog of document use data. User control over the data is also enhanced - it's now possible to forget about individual documents from the context menu, instead of being forced into a complete wipe.
    But that's not all on the documents front! Activities enable both Application Menu and Task Manager to easily query for recent documents by the application they were opened in, leading to lists of recent docs in the context menus of various types of application launcher buttons:

    Per-application recent documents in Application Menu and Task Manager 5.3
    Per-application recent documents in Application Menu and Task Manager 5.3

  • Recent Contacts is a brand new addition to Application Menu 5.3 showing the people you've been in touch with recently, along with their realtime status information. The first part of this is handled through Activities; dealing in people data, however, is facilitated by a recent addition to KDE Frameworks 5: KPeople.


Application Menu's Recent Contacts category in Plasma 5.3
Recent Contacts in Application Menu 5.3: Powered by Activities and KPeople

The KPeople framework allows applications (including the shell) to retrieve lists of people and information about them (status, contact metadata), as well as perform actions on them - e.g. initiate a chat, as used by Application Menu when you click on an entry in the Recent Contacts category.

The data backing this interface is provided by backend plugins. The first implementer of a fully-featured KPeople backend is of course our very own Telepathy instant messenging suite. In the future, other KDE communication apps will integrate with KPeople, making conversations had e.g. in KDE's IRC client Konversation pop up in Application Menu as well.

Closing thoughts

Both the enhanced Activities backend and KPeople are very fresh. While we work hard to line up everything behind them (implement additional data sources and optimize those implementations, for example), they are still exposed somewhat carefully in Plasma Desktop 5.3. The Recent Contacts category in Application Menu, for example, is disabled in this release by default, because a Telepathy release entering conversation data into the Activities knowledge store is still pending. It can be enabled from the widget's config dialog.

In future releases you can expect us to make more of these pillars as our confidence grows, with additional UI functionality built on them and more prominent placements of it in various areas of the shell. Lots of work ahead!


Improving KDE's support for Korean (and other CJK languages)

The Hunminjeongeum (or 훈민정음). This 1446 document first introduced the modern Korean writing system to the Korean people and is now listed among the UNESCO Memory of the World. (Photo: Jeon Han, CC BY-SA 2.0)

In addition to my usual work on things like Plasma, I've been hacking away on bugs that pose barriers to the use of the Korean language and writing system in KDE/Qt systems lately (I took up studying Korean as a new hobby). As a bonus, many fixes also tend to help out users of other CJK (Chinese, Japanese, Korean) languages, or even generally of languages other than English.

Localization defects come in many shapes and forms and tend to be fun puzzles to solve, with lots of vertical cross-cutting through the stack. Here's a few examples from my plate in the past half year:

Kate: Input method / IME / ibus support doesn't seem to work well in KF5 version and the resulting Qt: ibus plugin badly maps text attributes to QTextCharFormat

On Linux systems using IBus for complex writing system input (which is most of our desktops), Qt 5 would generate QInputMethodEvents with badly-formed formatting directives, causing pre-edit text (such as incomplete Hangul blocks) to turn invisible in some applications. This fixes text entry in Korean and any other language doing complex in-line composition in KWrite/Kate, KDevelop and other applications built on KDE's KTextEditor framework (and likely others).

Amarok: Podcast save location containing Korean characters are garbled

A fun mess where a chain of QString::arg() calls against a template string would go awry by replacing a URL with percent-encoded Korean into the template, causing subsequent calls to trip up on unexpected % placeholders. Your Korean podcasts will now work nicely again in Amarok.

KCodecs and kdelibs: KCharsets does not support CP949 encoding

Code page 949 is a superset of the EUC-KR character encoding. Introduced by Microsoft, it supports additional Korean characters not supported by EUC-KR and remains in use on some Korean websites and IRC networks (unfortunately - please switch to UTF-8!). QTextCodec gained support for CP949 in the Qt 4.x series, but our KCharsets was never sync'ed up to those enhancements, hiding the codec from selection UIs throughout KDE's products. The effective impact of this is reduced somewhat by Qt 5's support for ICU, which is smart enough to handle CP949 transparently in EUC-KR mode, but the situation was still confusing for users nonetheless (and left broken when running non-ICU builds of Qt).

This last one is interesting because patches to address this were actually supplied by the community in 2010 already, but they sat around unloved until recently despite not being very complicated - developers are often reluctant to engage in tickets like this because they feel out of their depth, or simply struggle with the setup necessary to reproduce a problem. I worry this may cause a bad feedback cycle of bugs not being reported by users who don't have the time or energy to educate developers about the problem space.

If you're a user of Korean (or other CJK languages) and KDE, please do report them. I'll be keeping an eye out. If you're a developer and struggling with Korean or CJK support in your application, you should consider getting in touch, too.


Beyond Unicode: Closing a gap in the support for mixed character set text in KDE workspaces

Mixed character set text

Not long ago, the various language spheres engaged in computing maintained seperate, private standards for encoding the characters and symbols used in their written communication. This made it hard or impossible to author documents (or provide a user interface) mixing characters from multiple spheres. Unicode and its various encodings have mostly addressed this problem (though not to everyone's satisfaction, keeping some narrower encodings alive for some time yet), which has been wonderful for information sharing across the globe.

However, we have a similar situation to the old incompatible-encodings mess on the presentation layer. Font files typically only include glyphs for one or a small number of writing systems, e.g. Latin and its offshoots, or the Korean Hangul alphabet and the hanja sometimes used by Korean speakers. There are efforts to create more comprehensive "Unicode fonts" (e.g. Google's Noto family), but it's likely they'll remain few: Type designers tend to stick to the characters they're intimately familiar with, and most type faces are designed by small, localized teams sitting in this or that country. Trying to design glyphs for an alphabet you haven't used is a tall order (though it would be awesome to see more designers try and rise to the challenge).

Even monolingual documents increasingly source from more than one character set: Emoji are a thing, and it's getting bigger every day. Right now, few fonts provide their own emoji glyphs; they're usually stored separately (more on that in a moment).

The problem

Here's a screenshot of the font settings for the Plasma Desktop workspace:

Applications run inside Plasma Desktop inherit these settings. For example, Konversation, KDE's IRC client, will default to using that "General" font to display chat messages. Konversation also has a config knob to deviate from the system default and use a custom font, of course; it looks very similar.

Now consider a mixed-language, mixed-alphabet chat: English, written using the Latin alphabet, will use the glyphs from the wonderful Fira Sans. But Fira Sans doesn't contain any glyphs for the Hangul alphabet, so what will happen to a message containing any Korean text? Or any emoji, for that matter?

Enter glyph substitution: The font stack on Linux - and another platform we'll look at alongside, Windows - is smart enough to handle the case of a missing requested glyph, and supports sourcing it from a different font instead.

How this fallback lookup happens is governed by fontconfig configuration files. Fontconfig allows one to specify one or more aliases for a font family, and in case of missing glyphs, the system will try and locate them in one of the families specified as aliases. MyLatinFont can have MyHangulFont as an alias in the system, and Konversation will wind up displaying that Korean text using the Hangul glyphs from MyHangulFont, even when nominally configured to use MyLatinFont. This is roughly the same mechanism used to make generic family names like Sans Serif work and map them to actual, specific fonts.

In practice, this means your typical desktop-y Linux distribution maintains a large set of configuration files in /etc/fonts/ trying to provide reasonable fallbacks, and trying to anticipate what font packages you might install. Windows actually works almost exactly the same way - there's an alias mechanism, controlled by the registry, with some default mappings hardcoded into Uniscribe and others getting installed by Windows' language packs.

The problem with this is the lack of user control. Neither Plasma Desktop nor Windows provide any graphical means to influence glyph substitution behavior. You get to set one font per UI role, and what happens in case of missing glyphs is left to distro-maintained config, or your hand-written config files (on my system, I maintain an elaborate ~/.config/fontconfig/fonts.conf for this reason). There's no easy way to pick "your Korean font" or "your emoji font" if your font settings point to Latin-focused fonts.

This only affects a few users now, but it's users in the very interesting position of bridging multiple language spheres, a use case I feel we should care deeply about in KDE. And with the rise of Unicode-based emoji, it's a growing problem.

Mulling a solution

So I've been wondering how we could improve the font settings in Plasma Desktop to address this problem. One approach would be adding an "Advanced" sub-dialog exposing the fontconfig alias machinery in a very straight-forward way, loading in the system-level mappings and allowing user-local variation of them. But this would clearly result in a very user-unfriendly, highly complex interface.

I'm thinking a better fix would be to enhance our font management UI to let users create virtual user fonts: We add a Create Font button bringing up a dialog that lets you specify a name, a base font, and an ordered list of fallback fonts. Once saved, this virtual font becomes available in the font settings of both the workspace and applications, under the user-chosen name.

This would allow users to easily compose a MyChatFont sourcing from different real fonts, for different character sets including emoji. Implementation-side, it would (mostly) work by writing out aliases to the user-level fonts.conf (which we already write things like rendering settings to today).

There's a bunch of traits to this approach that I find compelling: Users are already familiar with the idiom of picking a font from the list, and this builds on it by simply letting them expand the list with custom entries. Reverting settings is as easy as switching back to a real font. It's easy to set up different sets of settings (in the form of different user fonts) and use them in different apps. It stays out of the hair of the distro's alias config as much as possible. And it's extensible should means of font composition other than aliases (e.g. based on language-tagging) come along.

Putting it into action

I'm hoping to take a stab at implementing this pretty soon, to try it out in practice. But I'd love to hear your feedback on the general problem and the proposed solution - if you have any experience with how other workspaces tackle this problem (I haven't found any attempt yet) or are in possession of a piece of the solution already, please get in touch!


Konversation goes Frameworks 5

The Konversation team has started porting the application to Frameworks 5 earlier this month, getting things to build and run on top of KDE's next-generation libraries.

Here's all the info you should need to help out.

At this stage of porting there are still hundreds of low-hanging fruit (porting away from deprecated APIs, porting to slightly changed APIs, etc.) that don't require extensive knowledge of either the codebase or even the problem space to tackle, so if you were looking to get your feet wet on Frameworks 5 or KDE development in general, consider chipping in!

In fact, one of the major risks associated with any porting is lowering the quality of the application by reducing functionality or just plain breaking things, and of course we'd like to avoid both. So you can even help out by just running the port and logging the things that don't work on KDE's bug tracker (handy link is on the wiki) as tasks for others to jump on.


The Birth of Plasma 5

I'll keep things brief, since I'm inbetween KDevelop windows right now: It's out today, and in my mind it took just about nine months to make it. Nine months, now that's a timescale with some cachet.

Back in September, we had this, as best as memory serves:

  • A rough initial ramp-up of the freshly-refactored low-level Plasma libraries on top of Qt 5 / Qt Quick 2.
  • And on top of a similarly rough-and-in-motion Frameworks 5.
  • A Plasma shell application that could render a basic wallpaper (with no config yet).
  • A few "test this library API" widgets.
  • Very broken and very empty panels.
  • And we were still running this inside the old Plasma Desktop 4, since we didn't have kwin yet, or an actual session.

Since then, we:

  • Rewrote about 80% of the core Plasma Desktop components from scratch, with significant improvements in some areas (e.g. the tray and notifications).
  • Ported the rest over from 4.x, often with significant cleanup and non-trivial changes.
  • Created hundreds of new visual assets from scratch.
  • Ported many, many support and system integration bits, such as network management, while continuing to make significant improvements to them.
  • Kept contributing fixes and features to Qt 5 in a major way.
  • Continued porting and modularizing KDE's libraries, and finally shipped them as Frameworks 5.0.
  • Not insignificantly, kept up supporting and releasing KDE 4 in parallel (with a major overhaul of the semantic desktop implementation in 4.13).

Kick-ass. It's been an amazingly productive time in the KDE community lately (not just in Plasma and Frameworks - KF5 porting of apps is going on as well!), and we'll be back in just three months with yet more.

Back to KDevelop.


A Yakuake update: Frameworks 5, Wayland, More

Things have been rather quiet in Yakuake land for a while. 2014 is going to shake things up, though, so it's time for a brief look at what's been going on and where things are headed next.

Frameworks 5

Not long ago I pushed an initial port of Yakuake to Frameworks 5, the next generation of KDE's platform libraries, to Yakuake's git repository. The new code lives on a branch called frameworks for now.

Yakuake on Frameworks 5 is functional and free of the use of any deprecated APIs. The port is mostly complete, too, missing just a few more touches to the first run dialog and skin handling. Here's a screenshot:

Yakuake on Frameworks 5
Ah yup: Looks no different.


One of the broader initatives the community is engaged in this year is enabling our workspaces and applications to use Wayland. Yakuake may just have a small role to play in that.

Historically, Yakuake's relationship with window managers has been plenty interesting. It's managed to crash several of the popular ones at one point or another; it's an unusual application with unusual behavior that exercises window manager code differently from more typical apps. More recently, it was perhaps the first non-workspace process to communicate and collaborate tightly with the compositor, asking KWin to perform the slide-in/out animations on its behalf if available.

The latter is a model for things to come. In Wayland, application windows know intentionally little about the environment they exist in, and instead have to petition and rely on the window manager for things like positioning with no recourse. Yakuake on X11 does this legwork by itself; on Wayland, the comm protocol to the window manager will have to be rich enough to allow for equivalent results.

Having Yakuake ported and ready will allow for it to serve as a useful testcase there.

General feature plans

Yakuake's theming system has been showing its age for a while, so I'm looking to implement a replacement for it. The new system will be based on QML, taking some inspiration from KWin's Aurorae decoration engine. The result should allow themes to support anti-aliased edges and shadows, along with much more flexible control over the placement of Yakuake's UI elements. Existing themes will continue to be supported however (by way of new-format theme that knows how to load and display the old ones -- the config UI will list both types transparently in the same list, though).

The other major feature that's been a long time coming is proper support for session restore. This has mostly been held back by missing functionality in the API of the Konsole component that provides Yakuake with terminal emulation. Unfortunately that situation remains unchanged for now, but I'm still hoping to eventually get around to some Konsole hacking to satisfy Yakuake's needs there.

Schedule thoughts

Frameworks 5 uptake in distributions has been very promising so far, with several distros (I'm aware of Fedora and Kubuntu, but there are no doubt others) packaging the preview releases soon after they were announced. It's still pre-release software, though, and APIs might still change until the stable release this summer. Until it's out, the repo's master branch will therefore continue to contain the KDE 4 codebase, and there will be another maintenance release cut from it sometime soon.

Development of the new theming system will be targeted at Qt 5 and Frameworks 5, however, due to significant API changes in the new Qt Quick and QML generation. As with the next KDE 4-based release there's currently no firm date for this - Aaron makes a good case for not rushing things - except to say it will be some time this year.


KDE Plasma at the movies

For several years, I used to maintain a collection of clippings showing the KDE workspaces in use in interesting settings - popping up on TV shows, on public terminals in odd locations, in articles on leading scientific endeavours. All sorts of cool cases. More recently I haven't been collecting as diligently anymore, though, for perhaps the best possible reason: It's happening so frequently now that individual examples have lost much of their novelty.

But from time to time it still provides me with a (pleasant) shock to the system to see our software help others push the envelope and create amazing things. The latest example occurred just the other day, while I was watching the making-of documentary for Alfonso Cuarón's impressive film Gravity:

KDE workstation at Framestore

KDE workstation at Framestore

Framestore worked for several years to provide the majority of the film's effects shots, and their London-based offices appear filled to the brim with workstations running KDE Plasma. I think I may have even spotted Yakuake on a panel in there.

Interestingly, Framestore isn't the only London-based VFX house using KDE software. I previously collected a snapshot of Doctor Who VFX provider The Mill using Plasma Desktop in their work as well.

One factor driving this adoption is perhaps the synergy between our and the industry's extensive use of and familiarity with Qt - many high-end 3D modelling and video editing/compositing packages now use Qt for their UI, and often provide PyQt as convenient extensibility solution for in-house dev teams at the studios. The same is true of KDE. But I'd like to think providing a damn nice desktop experience also has something to do with it :).

In the thick of competition, or looking purely at market share data, it's sometimes easy to forget just how much real and compelling use the stuff we make is seeing in absolute terms. And the degree to which our software permeates the foundations that big chunks of our culture get built on top of.

It's nice to reflect on that now and then.

Gravity has been nominated for ten Academy Awards recently, including the Best Visual Effects category. I loved it, and have a feeling it has a pretty good chance.