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