Do you want Catalonia to be a State? If so, do you want Catalonia to be an independent State?

Today there are only six days left until I vote in the independence referendum. I usually use my personal blog for non technical bits but I thought some readers of my KDE Blog might be interested in this as it does affect the geopolitics of pretty much the whole world.

What's going on?


Kubuntu Vivid in Bright Blue

Kubuntu Vivid is the development name for what will be released in April next year as Kubuntu 15.04.

The exiting news is that following some discussion and some wavering we will be switching to Plasma 5 by default. It has shown itself as a solid and reliable platform and it's time to show it off to the world.


Beyond the color pickers

Andy, thanks so much for picking up the topic of color pickers (pun intended).

I'd like to discuss cases when accuracy is not as important at results. In this case there's a problem of abundance of choice. You don't have time to quickly and correctly pick one from the 16777216 colors. Plus alpha value? Come on! Whenever you're confronted with a photoshop/gimp-like color picker you either choose random color, or single color that's globally predefined in a palette. I also understand that very few 'casual' users maintain own palettes for consistency.


Ubuntu's Linux Scheduler or Why Baloo Might be Slowing Your System in 14.04

Last month I posted about packaging and why it takes time. I commented that the Stable Release Update process could not be rushed because a regression is worse than a known bug. Then last week I was pointed to a problem where Baloo was causing a user's system to run slow. Baloo is the new indexer from KDE and will store all your files in a way you can easily search for them and was a faster replacement for Nepomuk.


2.8.6 → 2.9 → 3.0 → ...

That was my first Akademy after a while, I've been following previous two with kids on my lap. I think Brno turned out to be both a pretty destination and decent host for all KDErs.
A new Kexi contributor Wojtek Kosowicz came with me. You can read about him here and his recent story here. Recently in Kexi there is a trend of new contributors coming from Poland, and specifically from Warsaw. I've heard they're a bit regretting afterwards they didn't join the Akademy too but I trust that will improve next year :)


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!


Kexi Report Designer Jobs

It's not a secret that reasonable explained and mentored junior jobs attract new great contributors.

Based on a popular request, here's massive list of 10 new Junior Jobs for Kexi. Now they are mostly related to Kexi Report Designer, which receives a lot of love recently as an unique Free Software solution of this kind.

Be sure to ask for details or request different kind of junior jobs... there are basically thousands of them :)

SQL car by jepoirrier, CC BY-SA 2.0


Akademy Day 1 Photo Blog

Some of the Kubuntu Devs

Talking and hacking in the corridor

Sebas celebrates the release of Plasma 5