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.