Bug 84606 - kxkb group switching using just the Right Win doesn't work (+ugly workaround HOWTO)
Summary: kxkb group switching using just the Right Win doesn't work (+ugly workaround ...
Status: RESOLVED FIXED
Alias: None
Product: kxkb
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Andriy Rysin
URL:
Keywords:
: 44808 83958 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-07-07 01:51 UTC by Vassilii Khachaturov
Modified: 2007-10-09 05:33 UTC (History)
4 users (show)

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 Vassilii Khachaturov 2004-07-07 01:51:05 UTC
Version:           ��� (using KDE 3.2.2,  (testing/unstable))
Compiler:          gcc version 3.3.3 (Debian 20040401)
OS:                Linux (i686) release 2.4.25-1-686

I am using several layouts on my computer, and manage the switching only via the
KDE layer - because I really like the sticky switching and the flag it provides.

Because I am used to mapping the rwin key to cause the group toggle from the way
it is set up on the Linux console (where I switch using the console-cyrillic 
Debian package), I wanted to set up the same thing over in KDE.

In my XF86config, I *do not* do any fancy layout mgmt:
Section "InputDevice"
        Identifier      "Generic Keyboard"
        Driver          "keyboard"
        Option          "CoreKeyboard"
        Option          "XkbRules"      "xfree86"
        Option          "XkbModel"      "pc104"
        Option          "XkbLayout"     "us"
EndSection

The natural way (using the path of the least resistance through the KDE GUI) didn't
work, but I nevertheless achieved the desired result using an ugly hack. Detailed
description of both follows.

In layouts, select several layouts (> 1). (I tested with 2-5 different layouts
out of the set of US, US intl w/dead keys, Hebrew, Russian, Spanish, French, Italian
and German.) I also enabled the sticky switching. These things are common to both
the working and the non-working solution.

Now the intuitive thing that doesn't work:
on the xkb options tab, select "enable xkb options",
"reset old options", then, in the "group switching" subtree,
select "Right Win-key changes group".
Apply the things, and try the Right Win-key. It doesn't work, but this is
probably just an instance of
http://bugs.kde.org/show_bug.cgi?id=59442

So kill KDE and restart, and verify the options are there in the kxkb. Right Windows
key still doesn't do it. Ouch.

Now the ugly workaround comes.
Disable back the "group switching" subtree selection,
and in the "Third level choosers" subtree set the Right Win-key to choose the third
level. Now, apply the changes. Go to the keyboard shortcuts via your control panel
(`kcmshell keys' from the command line). There, in the Global Shortcuts tab,
add to the "Keyboard/Switch to next keyboard layout" shortcut a custom shortcut
- and press the rwin key recording it. You should see ISO_Level3_Shift now
as the alternative combination. Apply the changes.

That's not all. Unfortunately, until you log out and log back in (maybe it's possible
to just restart smth inside KDE, but I didn't investigate this), at least on my
machine, with the default modifiers scheme, pressing rwin raises the application menu.
When you log back in, you finally get what you wanted - right win changes the group,
you can verify it with the flag icon in the tray, and it actually changes the keyboard
layout.

Without the level3 thing, this won't work because then rwin will just stay a
modifier key, and currently the shortcut recording doesn't allow for modifiers-only shortcuts.

Overall, the internationalization UI is very counterintuitive right now. It's a pity
that there is no way to learn about the group switching shortcut from within kxkb,
and vice versa, about kxkb when configuring the keyboard shortcuts. Here, however,
I am unable to provide constructive critics because I'm pretty dumb in the UI design.

The bug is consistent, and doesn't depend on which language and primary locale (I didn't
try UTF-8-based locales, though) the local user uses.
Comment 1 Vassilii Khachaturov 2004-07-07 02:39:49 UTC
Debian twin bug xref:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257984
Comment 2 Andriy Rysin 2004-07-07 09:49:24 UTC
do you use 'Include latin group' option?
Because if you don't, in XFree starting 4.3.0 there's only one group in each layout by default (unless you changed options in /etc/X11/xkb/rules/xfree86) and thus group switching does not make much sense.
Comment 3 Vassilii Khachaturov 2004-07-07 11:11:23 UTC
Andriy,
thanks for your prompt reply.

On 7 Jul 2004, Andriy Rysin wrote:

> do you use 'Include latin group' option? Because if you don't, in XFree
> starting 4.3.0 there's only one group in each layout by default (unless
> you changed options in /etc/X11/xkb/rules/xfree86) and thus group
> switching does not make much sense.

The bug behavior has been verified with and without the "Include latin
group" simultaneously selected on each layout. Between the attempts,
after the kxkb changes were accepted, kde was restarted. The
only effect of this option is that one can do "Ctrl+..." even
with the non-Latin layout selected, and it will work; with and without it,
kxkb still ignores the requested group toggle behavior of rwin.

Vassilii

Comment 4 Andriy Rysin 2004-07-10 20:27:07 UTC
Now I see what you mean. The problem is that by default or in your X configuration X treats Right-Win as a modifier so you cannot assign shortcut just to Right-Win. When you switch Right-Win to 'xkb group changer' then is becomes standalone key wich you can bound to layout switching.
It's not a problem of kxkb - I can transfer this issue to general kde but it's just the nature of X and I am not sure it can be helped easily.
The main problem here is that X and KDE are different products and don't integrate too tightly.
Lubos, you may be more familiar with this, could you please comment this issue?
Thanks.
Comment 5 Andriy Rysin 2004-07-10 20:37:28 UTC
*** Bug 44808 has been marked as a duplicate of this bug. ***
Comment 6 Andriy Rysin 2004-07-10 21:25:05 UTC
*** Bug 83958 has been marked as a duplicate of this bug. ***
Comment 7 Vassilii Khachaturov 2004-07-10 21:53:46 UTC
> Now I see what you mean. The problem is that by default or in your X
> configuration X treats Right-Win as a modifier so you cannot assign
> shortcut just to Right-Win.

Correct. It is the default - I didn't do any local maps change.

> When you switch Right-Win to 'xkb group
> changer' then is becomes standalone key wich you can bound to layout
> switching.

This is the nature of my workaround hack.

> It's not a problem of kxkb - I can transfer this issue to

I still think there is a problem with the kxkb because its UI is
misleading. If there is an option there that suggests that if one
selects it, it would be possible to use rwin as the group toggle,
it is only natural that an average user (that doesn't know a modifier
from a normal key) will be happy to select it and then become
frustrated because of it. Also, there is this ugly separation between
the shortkuts configuration and the switching configuration in kxkb,
I am sure a lot of people have only seen one but not the other.

> general kde but it's just the nature of X and I am not sure it can be
> helped easily. The main problem here is that X and KDE are different
> products and don't integrate too tightly. Lubos, you may be more
> familiar with this, could you please comment this issue? Thanks.

Comment 8 Andriy Rysin 2004-07-10 22:07:27 UTC
Well, the point here is that it works for AltWin and it may work for Alt+Shift but it may not work for Ctrl+Shift or Ctrl+Alt, so we can not make this as a standard option for an average user. The ugly workaround - that's what it is.
I put 'Xkb option' to kxkb configuration panel because X implementation is pretty complex and cumbersome in xkb area and I just wanted some 'advanced options' to be accessible to the (advanced) people who want to use them. 
It may happen to enable some missing KDE features but it was not designed to do so and it's not possible to make this standard. I could remove 'xkb options' altogether but I think that many people use it for other needs and they will not be happy about that.
The only proper way is to tweak kdelibs (?) to be able to use modifiers as shortcuts without ugly hacks. Thus kxkb will not be directly involved into proper solution.
Comment 9 Vassilii Khachaturov 2004-07-11 10:22:56 UTC
> Well, the point here is that it works for AltWin and it may work for
> Alt+Shift but it may not work for Ctrl+Shift or Ctrl+Alt, so we can
> not make this as a standard option for an average user. The ugly
> workaround - that's what it is.

Agreed :)

> I put 'Xkb option' to kxkb
> configuration panel because X implementation is pretty complex and
> cumbersome in xkb area and I just wanted some 'advanced options' to be
> accessible to the (advanced) people who want to use them.  It may
> happen to enable some missing KDE features but it was not designed to
> do so and it's not possible to make this standard. I could remove 'xkb
> options' altogether but I think that many people use it for other
> needs and they will not be happy about that.

Indeed it would be very gruesome if this is removed altogether.

> The only proper way is
> to tweak kdelibs (?) to be able to use modifiers as shortcuts without
> ugly hacks. Thus kxkb will not be directly involved into proper
> solution.

I wonder if kxkb could transparently do smth along the lines of the hack
- check if it is a modifier first, then, if it is, verify that no
shortcuts using it exist (otherwise give a warning they will no longer
be accessible). Then, transparently remap the modifier into some unused
code, and then use that code as the switching shortcut. Obviously,
this would be much more than is possible during the current approach
that just takes the GUI selections and blindly translates them
into a setxkbmap cmdline.

Comment 10 Munzir Taha 2004-07-12 00:51:13 UTC
Actually the trick whether called ugly or not is very valuable to me. Thanks.
Comment 11 Lubos Lunak 2004-07-13 15:48:19 UTC
I think it should be possible to make the shortcut dialog accept only modifier key(s) as the shortcut, and modify KGlobalAccel accordingly. It probably doesn't make much sense for other apps than kxkb though.
I don't understand what the rest of the bugreport is about, too xkb-ish to me :(.
Comment 12 Vassilii Khachaturov 2004-08-30 12:45:45 UTC
Is there a way to do a similar trick with "CAPS"? The difficulty for me is that "CAPS changes group" doesn't work just like the "Right Win changes group"; however, there is no CAPS option in the level3 chooser key selection.

(If you are curious, I am wokring on a laptop at this where there is only one (left) win key present; I worked it around by assigning the level3 switching to the right CTRL, but it isn't very neat as I keep hitting it by accident :( ).
Comment 13 Vassilii Khachaturov 2007-04-12 23:48:13 UTC
If one adds the German ("de") keyboard layout, the workaround
I had earlier described in this thread works for switching TO the
German keymap, but doesn't work to switch back FROM the German
keymap.

(Tested with KDE 3.5, debian Etch + some unstable stuff on the machine).
Comment 14 Andriy Rysin 2007-10-09 05:33:35 UTC
In KDE4 kxkb switches groups instead of layouts so this should not be a problem any more.