Bug#362030: kdebase-bin: kxkb: improve keyboard layouts explanation (and functionality?)
Package: kdebase-bin
Version: 4:3.3.2-1sarge1
Severity: wishlist
I think you can improve the GUI to make it more intuitive and the
handbook to explain things better. Any maybe you can add functionality.
Let me first say that there are many things I like about kxkb:
-- country flags to show the current layout (or "err" if there is an error)
-- kxkb shows the setxkbmap command line (useful for learning/debugging!)
-- you can set up more than four layouts (does anyone use this feature?)
-- you can switch keyboard layouts per-application or per-window.
Now come my criticisms. The xkb options "don't work". Actually, they work
very well, but they don't do what users may reasonably expect.
If I understand things correctly, there are two ways to change keyboard
layouts, the native X way and the KDE way. Co-operation between the two is
restricted in ways the user may not expect.
In particular, it is easy to get the impression that the xkb group switching
options (shift keys, LED indicators) can be set up to switch the layouts
selected in the kxkb layout tab.
So it looks as if the group switching "doesn't work".
I know that I got this impression. From the discussion at refs [1] and [2] it
looks as if Vassilii got this impression. I conclude that many less skilful
people will give up in disappointment, and even those who succeed will suffer
frustration along the way. It took me several hours to figure out the
details, and I had to learn more about keyboards than I ever wanted.
[1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257984
[2]http://bugs.kde.org/show_bug.cgi?id=84606
I think we can do better than "X and KDE are different products"[2].
I have three proposals. I will try to keep them short, because I am stuck
with Debian Sarge (kdebase-bin 3.3.2-1sarge1) so I don't know if things have
improved already.
(1) Make the GUI clearer
In the tab "xkb options" the heading "Group Shift/Lock behaviour" is cryptic
for non-experts. Change it to something like "Group switching (for switching
xkb groups within the current layout, eg latin & cyrillic)"
(2) Make kxkb handbook clearer
Include an early section on "when *NOT* to use keyboard layouts". Users of
Win9x may think there is no other way. Encourage the user to learn keystrokes
on their default layout. Explain the powerful concept of "deadkeys". Maybe
point to a suitable webpage or include a lengthy appendix. Definitely give
examples. Eg if you live in the UK, you probably have a "Generic 105-key
(intl) PC" keyboard with layout "gb". Then you can do:
(acute accent) AltGr + ; followed by a,e,i,o,u,A,E,I,O,U
(circumflex) AltGr + ' followed by a,e,i,o,u,A,E,I,O,U
(grave accent) AltGr + # followed by a,e,i,o,u,A,E,I,O,U
(German Umlaut) AltGr + [ followed by a,e,i,o,u,A,E,I,O,U
(German Esszett)AltGr + s
(tilde) AltGr + ] followed by vowel or n
And please tell me how to do c-cedilla!
[Tranlators of the kxkb handbook should be encouraged to include a suitable
example for their locale.]
Only *then* explain *how* to use keyboard layouts. Include something like
my paragraph above (there are two ways to change keyboard
layouts, the native X way and the KDE way. Co-operation between the two is
restricted in ways the user may not expect).
Maybe give a bit of detail of the two mechanisms:
native X
-- the X server knows up to four layouts
-- can toggle between them using "group switching" commands, which can be
bound to various shift keys etc
-- can use keyboard LEDs as indicators
KDE
-- each user can set up one or more layouts
-- can switch using mouse click or keystroke (default: ctrl+alt+k)
-- keyboard indicator in panel
-- can maintain separate keyboard settings per application or per window
Explain (assuming this is true!!) that in order to provide this fine-grained
control, KDE sends a new "setxkbmap" command every time the user changes to a
new application or window. This is the commandline shown in the "layout" tab.
Explain that you can select many layouts in KDE, but at any given time, X
knows about only one layout (or two if you clicked "include latin layout").
So if you pick two separate kxkb layouts, group switching will have no effect.
If you pick one layout (eg a cyrillic one) and click on "include latin
layout", then as far as KDE is concerned you have one layout (one country
flag) but you can toggle using the xkb options.
(3) Add functionality?
I live in Britain and have a British keyboard. So for me, "include latin
layout" doesn't work very well, because it should include "gb" not "us".
A real-world example: Anna's physical keyboard is British, but she wants to
type lots of German. She learnt to touch-type in Germany. It is far quicker
for her to use a German layout and type ";" for "ö" rather than using the
British layout with Umlaut-deadkey combinations. But sometimes (for rarer
punctuation and stuff) she wants to look at the keyboard and toggle back to
the British layout. She needs a win-key toggle or similar, rather than mouse
clicks or Ctrl+Alt+k.
In plain X11 (version 4.3.0) I can modify /etc/X11/XF86Config-4 like this
Section "InputDevice"
Identifier "Generic Keyboard"
Driver "keyboard"
Option "CoreKeyboard"
Option "XkbRules" "xfree86"
Option "XkbModel" "pc105"
Option "XkbLayout" "gb,de"
Option "XkbVariant" ",deadgraveacute"
Option "XkbOptions" "grp:win_switch,grp_led:scroll,grp:sclk_toggle"
EndSection
But in kxkb, I can't. So Anna can't get these settings per-user or
per-window. That's a pity.
Is there an intelligent way to improve the "include latin layout" option?
(Yes, I know it was partly a hack to restore old-X behaviour.) Maybe get it
to choose an intelligent default (not always "us") from the X server? from
XF86Config-4?
Or add a button to "include sublayout"? We could have "primary layouts"
(switched by KDE) and explain that each can consist of up to four "sublayouts"
(switched by X).
Before you say this is unworkable or too confusing, consider that the current
(sarge) kxkb doesn't grey out buttons as much as it could/should.
For example, "add" could be grey unless I have selected a layout from the
list on the left. "Remove" could be grey unless I have selected a layout
from the list on the right.
There also seem to be other bugs with those buttons:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361733
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=362017
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.27-3-686
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Versions of packages kdebase-bin depends on:
ii kdelibs4 4:3.3.2-6.4 KDE core libraries
ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libfam0c102 2.7.0-6sarge1 client library to control the FAM
ii libgcc1 1:3.4.3-13 GCC support library
ii libice6 4.3.0.dfsg.1-14sarge1 Inter-Client Exchange library
ii libidn11 0.5.13-1.0 GNU libidn library, implementation
ii libpam-runtime 0.76-22 Runtime support for the PAM librar
ii libpam0g 0.76-22 Pluggable Authentication Modules l
ii libpng12-0 1.2.8rel-1 PNG library - runtime
ii libqt3c102-mt 3:3.3.4-3 Qt GUI Library (Threaded runtime v
ii libsm6 4.3.0.dfsg.1-14sarge1 X Window System Session Management
ii libstdc++5 1:3.3.5-13 The GNU Standard C++ Library v3
ii libx11-6 4.3.0.dfsg.1-14sarge1 X Window System protocol client li
ii libxext6 4.3.0.dfsg.1-14sarge1 X Window System miscellaneous exte
ii libxrender1 0.8.3-7 X Rendering Extension client libra
ii libxtst6 4.3.0.dfsg.1-14sarge1 X Window System event recording an
ii xlibs 4.3.0.dfsg.1-14sarge1 X Keyboard Extension (XKB) configu
ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime
-- no debconf information
Reply to: