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.