My involvment in KDE development actually stopped in Oct last year after I and my GSoC student Shivam Makkar finally pushed his project implementation to show keyboard geometry in keyboard config UI.
But looking at the number of bugs reported lately against keyboard module something is really wrong in the module so I may have to revive my KDE-fu :) and try to take a look at those problems...

Keyboard layout indicator: widget or tray icon?

When keyboard layout module was redesigned for KDE 4 it felt like indicators of sorts were to be done in widgets/applets instead of tray icons, so keyboard layout indicator applet was created. It does allow greater flexibility that systray icon on where to put it and how to size it. I learned though that the keyboard daemon can't control that applet much (e.g. hide/show automatically) so when multiple keyboard layouts are configured there was no way that indicator applet can automatically appear (like system tray icon does).
So the system tray indicator stayed in with the hope that the user could choose whether to use tray icon or keyboard layout applet (or both).

It seems though that on some systems both keyboard layout indicator applet and system tray icon appear together which confuses users: https://bugs.kde.org/show_bug.cgi?id=264886

Also the user can place the applet on the desktop and when that applet is clicked to switch keyboard layout the focus goes to desktop window which we need to ignore in "per application" and "per window" mode which leads to defects like this https://bugs.kde.org/show_bug.cgi?id=269661

One of the solutions is to remove keyboard layout indicator applet and leave only system tray icon. The opposite solution: only leave applet and remove systray indicator does not seem right as it'll force the user manually add keyboard indicator applet after configuring layouts which most probably will confuse a lot of users especially novice.

There's of course always third option - leave it as it is right now and if the user added both indicators let them remove one. :)

I learned over the years that removing features no matter how redundant they may seem does upset users a lot so I created little poll (at the top of this blog page) to check which indicator people use to at least have some idea about potential impact on users.

Keyboard layout switcher: three polls to vote on

I am doing a little survey on how keyboard layout indicator is used and would appreciate if you could vote on those three polls to the right of this post.
Thanks in advance!

Keyboard layouts: switch notification

So there's this (pretty old) feature request to show notification when keyboard layout is switched (https://bugs.kde.org/show_bug.cgi?id=66641). It's not too hard to implement that (although the KStatusNotifierItem is a bit limited in how the notifications can be set). But there's couple of questions I have and although it has 45 votes nobody replied in the bug so far so I'll post them here:

1) when keyboard switcher is in "by application" or "by window" mode and active window changes also switching current layout, would you want to see
notification as well? Or shall the notification be shown only for "manual" layout change? I would think you don't want that popup show every time you
switch the window, but then if you don't see the tray you would not know if layout changed...
of course we can add new UI option but there's quite a bit of them already so I would rather not unless I have to

2) would you care to set the notification timeout? or shall it just use some "system default" one? again the less new UI options the better, unless it's
really needed

Keyboard layouts in 4.7: two new features

4.7_Feature_Plan: kde-workspace

1. Global shortcuts per layout - seems like it's been a wanted feature for a while. This feature has been in master for some time so I am hoping to get some feedback (before 4.7 is released) as global shortcuts is not the most straightforward thing in KDE.

2. Remembering/restoring layouts for session. It was a bit more code than I wanted it to be (due to remembering layouts per application especially if spare layouts are on) but this bug (52095) has been there since 2002 (and couple of others have been duped to it) so those who were that patient definitely deserve it :)
Note: restoring layouts works for all switching modes except "By window". I am not sure if there's an easy way to restore layouts by window: currently keyboard daemon remembers layouts by WId which is transient. Theoretically we could try to store layout information into window properties
and let kcmserver restore them and then keyboard daemon will have to read that but that would be quite different from what it does now so that might take another 8 years to implement :)

Setting NumLock on startup, how hard can it be?

So there was some code in kcmmisc which was inherited into keyboard daemon which sets the numlock state at KDE startup. Well the code had some ifdefs but it wasn't too bad and it was working (for me that is). Though users started reporting problems. As I could not find what's really wrong and latest numlockx (from which originally code was borrowed) was working I just reborrowed from the latest numlockx version. Seems to have helped... for a while...
New bug reports started to come in, with various degree of problems, including numlockx not working for everybody either (https://bugs.kde.org/show_bug.cgi?id=256255).

Some of those problems were caused by another programs reusing or controlling NumLock state/LED but some seems to be real with no obvious reason and thus no fix.

The summary? Well 300-lines program (numlockx) to simply set a flag for keyboard modifier and a LED might be one of those reasons why Wayland would eventually deprecate x.org

P.S. if anybody knows how to reliably set NumLock please speak up, 'cause I am giving up on this bug :)

Tests for keyboard layout switcher code

I am strong proponent of test-driven development and thus was quite envy of Sergei's test pack in libxklavier. I am glad to inform that the first test for keyboard layout switcher code landed in the repository and more to follow.
I am actually surprised how few tests we have in kdebase. It's not easy to test UI code (even though basic testing is not too hard with QtTest) but there's plenty of non-UI lines in kdebase that could benefit from some checking. Hopefully with David's improvements to KDE test framework we'll see more testing of the core functionality.

Kxkb: "spare layouts" feature landed in the trunk

With 1192111 commit in trunk "spare layouts" feature (similar to sticky switching) is added which also allows to have more than 4 layouts. I'd appreciate if somebody can give it a try before 4.6.0 is out and let me know about the results.

Kxkb: spare layouts (poor man's sticky switching)

I am almost done with alternative implementation of much missed sticky switching. There were two reasons on why new implementation (and thus naming) differs:

1. The shortcuts - having base (1st) layout constant is critical for keyboard shortcuts to work in KDE, especially for non-latin layout users
2. It's simpler - this allows most of the switching still to be performed by xkb leaving only occasional map switches for KDE keyboard module

The idea of spare layouts is that only last layout of the base pack can be switched out for "spare" layout from the context menu. And the hope is that
a) most of the users will lock 2 layouts
b) users will switch more (e.g. in case of en-ru-uk set) between en-ru and en-uk than between ru-uk.

Under the hood only the base layouts are configured for xkb backend so pretty much any switching method uses standard xkb group switching (as in KDE 4.x) though when "spare" layout is chosen in context menu, the last of the base layouts is swapped out with the chosen one and xkb map is reconfigured.

One drawback is that switching to spare layout is slower (as the map is reconfigured - not just a group switch). This has also another slowdown for window switching if by-window/by-app mode is used - when active window changed and the map of the active window is different from the previous one reconfiguration has to be done. It's not extremely slow (~10-200ms in my tests) but definitely much slower than just a group switch.

I guess users who crave for sticky switching lived with slow switching so hopefully it'll be ok as it's much easier to let x.org do the group switching and just change the map occasionally rather than take over all the switching work in the keyboard module.

This approach also allows to have more than 4 layouts (xkb protocol limitaton) - if more than 4 layouts configured they will automatically become spare layouts.

Couple of snapshots: the configuration of spare layouts (gray background is the spare layouts) and the context menu look (first part of the menu is base layouts).

Kxkb: users survey done - the hard way

The simplest way to learn about features used in the software is to remove them. This happened when "sticky switching" was gone in KDE 4.0. And it happened again now with couple of smaller things in KDE 4.5 when the whole code of kxkb was rewritten to make it more scalable and robust (and with the years of workarounds knowledge learned handing xkb right it was long due). Often user's request is sane and implementation is fairly straightforward, sometimes though not quite. So the short list is:

• "Configure" item in context menu will be back in 4.6
• "Layout name over flag" won't happen unless somebody sends a patch which does it right (i.e. not the way it was before :)), BTW with old/new "Label" field for the layout "Layout name over the flag" is not that needed really, clear text or clear flag (if you don't use same layout base twice) are better option (IMHO)
• Simple adding layouts with drag-n-drop - not gonna happen soon: having two lists in the main config window makes it very busy especially that the source list is huge, plus it now needs to be filtered by language. Hopefully users don't configure their layouts too often so new additional dialog is not too much of a trouble. I'd like to make it more usable but it's pretty down at the bottom of my list
• Showing "setxkbmap command" - it's gone, it was too hackish for end-user and it just didn't belong there, in short "use kxkbrc file" if you need internal info
• Sticky switching & >4 layouts - these seem to be most favorite losses from KDE 3.5. We might have a solution on the horizon, so keep checking this blog ;)

BTW, there's no "kxkb" name in new "kxkb" module, it's now just a "keyboard": keyboard daemon, keyboard systemsettings module, keyboard layout applet. Though due to no new good abbreviation available (kde keyboard layout module - KKLM? ;)) and with still some popularity of the old one I'll keep using kxkb for this blog for now.