Summary: | Does not allow to select default layout variant for us keyboard | ||
---|---|---|---|
Product: | kxkb | Reporter: | Frans Pop <elendil> |
Component: | general | Assignee: | Andriy Rysin <arysin> |
Status: | RESOLVED DUPLICATE | ||
Severity: | wishlist | ||
Priority: | NOR | ||
Version: | 0.9 | ||
Target Milestone: | --- | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Frans Pop
2005-01-08 18:36:27 UTC
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. |