Version: 0.9 (using KDE KDE 3.3.1) Installed from: Debian testing/unstable Packages OS: Linux In previous versions of KDE, I had two keyboards selected: - U.S. English (us) - with default layout - U.S. English w/ deadkeys (us_intl) This allowed me to switch between normally entering ' and ~ and having these keys as deadkeys for accented characters. In KDE 3.3.1's kxkb, if I choose U.S. English, there are two layout variants to choose from: 'intl' and 'alt-intl'. Choosing the 'intl' option gives me deadkeys, which I don't want for the us layout. As I have no idea what the 'alt-intl' option stands for, I don't want to select that either; I would like to select the plain us layout, without variant. Like: setxkbmap -model pc104 -layout us Shouldn't there also be a possibility to select the us layout _without_ a -variant option? IIRC this used to be possible in previous versions. Note: The alt-intl variant seems to work like no variant was selected, but I haven't been able to find the definition for it to verify this. Anyway, I think the name alt-intl is confusing and not intuitive if you want to select a plain us layout.
The layouts are provided by the X11 files, not kxkb's. Can you select a no-deadkey layout by running: setxkbmap "us"?
I'm aware of that. Starting with the layout that's loaded when I select U.S. English (us) with variant 'intl': $ xprop -root | grep XKB _XKB_RULES_NAMES(STRING) = "xfree86", "pc104", "us", "intl", "grp:switch,compose:ralt" $ setxkbmap "us" $ xprop -root | grep XKB _XKB_RULES_NAMES(STRING) = "xfree86", "pc104", "us", "", "grp:switch,compose:ralt" And then I have no deadkeys (but the plain us layout). So yes, selecting U.S. English without a variant is a valid option. The only problem is that AFAICT kxkb does not support that (any more).
The other one seems to be against the correct component. *** This bug has been marked as a duplicate of 97108 ***
As far as I know (though I did not check it with latest version of X.org) the first variant which you get in the list is the default one. It's chosen by default and should be the same effect as selecting no variant at all. Actually there's always variant which is active for all layouts and when you're not specifying it in setxkbmap you get default one - the one which comes first in /etc/X11/xkb/symbols/pc/<layout> file (xkb_section). There may be a problem with "hidden" attribute though, currently kxkb HONOURS that attribute and does not show the variant in the list while setxkbmap may still use it by default. Sorry - lately I've been too busy to work on kxkb, so my info may be a bit outdated and I can't spend time checking it out. If the problem is with "hidden" attribute I'd connect with X.org people and ask them why "hidden" variants are used by default - I thought they should be used as an "abstract base classes" instead and their only function is to have real variants inherit from them.
Yes, you are correct. /etc/X11/xkb/symbols/pc/us has: default partial hidden alphanumeric_keys modifier_keys xkb_symbols "basic" { I have filed a bug against the xlibs package in Debian. From reading some X.org bugs, a solution in Debian has a good chance of making it upstream.
I'm seeing this on Gentoo with KDE 3.3.2, and though it makes sense that kxkb honours the 'hidden' attribute, shouldn't there be some sort of way for a user to force a hidden layout to be selected? Even if it's an option buried somewhere obscure, it's a world of help for those who need to wait for an X.org release just so kxkb works nicely. It's quite a hassle.
well, you either have to wait for new X.org or new KDE :) My understanding is that problems should be fixed where they are and not the level up. Besides there's no simple workaround - kxkb either have to stop honouring 'hidden' at all or we have to add checkbox 'allow hidden layouts' etc kxkb currently has too many workarounds for different problems with xkb in xfree86 and x.org, I see that future development for kxkb should go together with development in xkb (X.org) otherwise the there will be more code for workaround than for work itself. The other problem is that for last year I was too busy and not able to spend enough time even on supporting kxkb not to say about starting massive work of changes in xkb of X.org. If somebody would like to pick kxkb from me I'd be glad to help with my knowledge.