SEP
27
2016

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 KDE.org. 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. ☺

SEP
11
2016

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.

SEP
6
2016

Plasma 5.8: More efficient Pager and Activity Pager widgets

On the heels of the Plasma 5.7's new Task Manager backend, the upcoming Plasma 5.8 LTS release will sport substantially rewritten Pager and Activity Pager widgets, aimed at improving efficiency and conserving resources in a typical Plasma Desktop setup.

Plasma Pager widget
Enemy located

Two birds with one stone

Both the Task Manager and Pager widgets report on the windowing system. (If you didn't know: The Pager is the little game-like minimap to the left of the Task Manager, showing the windows on each virtual desktop.) To do so they need to know about the windows that exist and various things about them, such as their location (screen, desktop) and state (active, minimized). Up until now, the two would collect all of that data independently, sharing no code, and doing much of the same processing in response to changes. Plasma 5.8's Pager now shares a backend with the Task Manager (no matter how many instances of each applet you have), consolidating all the window information processing in the Plasma shell process in just one spot. This saves a whole bunch of CPU and memory, along with being less code to maintain!

Doing less is doing fast

The old Pager backend would toss out everything it knew about the current state of the windowing system every time any window changed in any way, causing everything the widget was showing to be torn apart and recreated from scratch - even when most of it didn't need to be touched at all. That's of course terribly inefficient, and the Task Manager's backend is fortunately much smarter. No more needless busywork.

Dropping weight

The way the Pager is actually drawn was cleaned up along the way, now using less CPU and memory, especially with the bare-bones default settings. Dragging a window on the Pager is now also much more efficient internally.

(Re-)joining forces

All of the above also applies to the Activity Pager widget - which used to be a lightly modified copy of the Pager's code, and now instead shares all of its code with its sibling. The two pagers remain separate entries in the Widget Explorer, but all further maintenance and development can now happen on a unified codebase.

MAY
31
2016

New Plasma Task Manager backend: Faster, better, Wayland

During the last several months, I've been rewriting the backend for Plasma's Task Manager, the strip of launchers and windows embedded into the panel at the bottom of the screen.

JAN
23
2016

What we do

Earlier this week, the loved one of a man I used to babysit was pushed into the path of an oncoming subway train car, by a stranger, and soon after died of their injuries.

While the death seems random, even cruelly so, it's one of many like it: Every year, people die on Berlin's various railways. Across Germany hundreds do, many of them similarly at metro train stations.

When disaster strikes, my thoughts soon dwell on analysis and prevention. For this particular case a well-demonstrated solution already exists: Platform screen doors, which I strongly hope the Berlin subway will eventually be retrofitted with.

As engineers, we deal in the makeup of the world all of us collectively inhabit. We help make and hammer away at the stuff of civilization.

We should all be offended by ill effects that may be prevented by means of better engineering. Our labor facilitates culture, but it's also on us to keep culture and its agents - people - safe.

It feels good that we enjoy many opportunities to act on our responsibility: Pick what we work on, weigh our concerns well, work diligently and pass on our knowledge. Make better engineering more affordable and available in this way.

This is true for any application of civil engineering, like a railway system, but just as much for any software system that users commute their thoughts and concerns through, if not their bodies.

JUN
3
2015

Folder View panel popups are list views again

In later versions of Plasma 4, the Folder View widget adopted a special appearance when placed in a panel: It would arrange folder contents in a simple list instead of the usual icon grid. Folder View had to be rewritten completely for Plasma 5, and while there were various improvements along the way, the list view mode unfortunately went missing. Until now - on popular request, this feature will make a return soon in Plasma 5.4:

MAY
21
2015

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 bugs.kde.org - 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 bugs.kde.org.

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.

MAY
17
2015

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
Completin'

Caveats

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 git.kde.org. You can browse the source , or skip straight to this clone URL:

git://anongit.kde.org/scratch/hein/kterustcompletion.git

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 KDE.org'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.

APR
28
2015

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!

APR
25
2015

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.

Activities

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.
     

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!

Pages