Bug 138510 - extra comma in Croatian layout with US variant
Summary: extra comma in Croatian layout with US variant
Status: RESOLVED FIXED
Alias: None
Product: kxkb
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Andriy Rysin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-07 19:34 UTC by Vedran Sego
Modified: 2006-12-28 08:51 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vedran Sego 2006-12-07 19:34:45 UTC
Version:            (using KDE KDE 3.5.4)
Installed from:    Fedora RPMs
OS:                Linux

When I select Croatian layout with hr keymap and us variant and turn on the "Include latin layout" option, the generated command is:
setxkbmap -model pc102 -layout us,hr -variant ,us
This leads to parts of the keyboard not responding, because the correct command should be
setxkbmap -model pc102 -layout us,hr -variant us

I've tried various settings, but none produced the result I desired (and was used to on Fedora Core 3): US keyboard which behaves as Croatian keyboard only while AltGr is pressed.

Btw, it would be nice if thath command line was user-editable.
Comment 1 Vedran Sego 2006-12-07 19:38:45 UTC
The workaround I'm using:

In xorg.conf, section "InputDevice", I've set the following options:
	Option	    "XkbLayout" "us,hr"
	Option	    "XkbVariant" "intl"
Works fine, but leavs me without the kxkb facility, i.e. I cannot switch to some othe layouts I would like to use from time to time.
Comment 2 Andriy Rysin 2006-12-08 01:00:17 UTC
Everything is correct.

You have selected Layout: hr, Variant: us and 'Include latin layout' option
In this case right one is:
 -layout us,hr -variant ,us
where
 -variant ,us
means empty variant for layout "us" and "us" variant for layout "hr"

If you don't want "us" variant for "hr" keyboard choose "default" variant (or any other, like basic or unicode)

then it'll be:
 -layout hr
or
 -layout hr -variant unicode

If you don't want latin group uncheck the option, the result:
 -layout hr -variant us
Comment 3 Vedran Sego 2006-12-08 04:05:13 UTC
Ok, let me expand what I've wrote previously.

> If you don't want "us" variant for "hr" keyboard choose "default" variant
> (or any other, like basic or unicode)

Now, my keyboard is plane HR, which I don't wont.

> If you don't want latin group uncheck the option, the result:
> -layout hr -variant us

No letters work now! Only top row (numbers and characters obtaned by Shift+number).

As I said,
setxkbmap -model pc102 -layout us,hr -variant us
behaves properly, but I cannot get it via kxkb interface. I do it by copiing
setxkbmap -model pc102 -layout us,hr -variant ,us
to konsole and removing the extra ",".

If the "-variant ,us" version is correct, then maybe this is a setxkbmap bug?
Comment 4 Andriy Rysin 2006-12-09 20:46:23 UTC
well, from what I understood when I was talking to xkb guys some time ago is that
"-layout us,hr -variant us" is doing next:
1. specifying "us" variant to "us" layout
2. specifying no variant to "hr" layout
thus it should be equal to "-layout us,hr"

I guess I've spotted the problem: in hr layout (/usr/share/X11/xkb/symbols) "us" variant was missing 'include "us"' line, it's been fixed in CVS of xkeyboard-config, you can check here http://www.freedesktop.org/wiki/Software_2fXKeyboardConfig

Comment 5 Andriy Rysin 2006-12-09 20:47:54 UTC
I am closing this bug, please let me know if new xkeyboard-config does not fix the problem. I'll see if I can reach its developers.
Comment 6 Vedran Sego 2006-12-15 03:55:12 UTC
Seems to be working perfectly.

Thank you very much!
Comment 7 Vedran Sego 2006-12-28 08:51:40 UTC
I am not going to reopen this, as I'm not sure if it is a kxkb or a setxkbmap thing, but there is one little issue: Alt+number (as in Alt+3 for 200% zoom in xine) still doesn't work (it does in US layout (variant <default> or basic).

It's not much of an issue for me as I rarely use it and can switch to US, but still wanted to document the problem here.

In Fedora 3, this all worked flawlessly with hr_us layout. I guess there is some problem in conversion to the current xkeyboard-config.

Btw, I think Slovenian and Bosnian keyboard should have the same correction(s) as the Croatian one, but I cannot confirm this as I don't use them. But their US variants (those corresponding to the Croatian one we're discussing here) are *not* US - they still use special CE characters instead of brackets, semi-colon, etc. Might be the same issue, though their config files differ significantly from the Croatian one.