Bug 17591

I am not happy with that patch - precisely because it is noncompatible. Would changing type of, say LWIN, to PC_ALT_LEVEL2 work as a separate option? I would doubt, but why not try it?

(Thanks for optimizing win_switch though).

I understand the compatibility may be very important in some cases but I am not sure about this exact case. As there is no type defined at all, it can be simply missing. Is there any _positive_ argument why that keys have to be of the default type?

Because the current behavior is annoying: with current definitions, it depends on the order(!!) of pressing the modifier keys. Win+Shift+key works but Shift+Win+key doesn't. You can try it if you set a second layout, for example:

setxkbmap -layout us,ru -option grp:win_switch

Win+Shift+s gives 'Ы' but Shift+Win+s does Multi_key action - nothing is printed and user is confused.

I can't find this intuitive or useful in any manner. Is there something I overlooked?

> I understand the compatibility may be very important in some cases but I am not
> sure about this exact case. As there is no type defined at all, it can be
> simply missing. 
Initially - quite possible it was just missing. Now it is whatever the default type for those keys is.
> Is there any _positive_ argument why that keys have to be of
> the default type?
No, other than compatibility, I do not see any positive arguments, I must admit. But in projects like that compatibility is God.

> Because the current behavior is annoying: with current definitions, it depends
> on the order(!!) of pressing the modifier keys. Win+Shift+key works but
> Shift+Win+key doesn't. You can try it if you set a second layout, for example:
Yes, I tried - I totally see your point. I am just thinking about minimal impact of the fix. 

So, I am asking again, would it be possible to make it XkbOption?

(In reply to comment #3)
> > Is there any _positive_ argument why that keys have to be of
> > the default type?
> No, other than compatibility, I do not see any positive arguments, I must
> admit. But in projects like that compatibility is God.
...
> Yes, I tried - I totally see your point. I am just thinking about minimal
> impact of the fix. 
> 
> So, I am asking again, would it be possible to make it XkbOption?

This is the base of the problem - I don't know the way how to make it _one_ XkbOption - because it is a problem how to make an option related to the logical key instead of the input key: we need to realize this condition:

a key mapped to Mode_switch in the level1 shall be of type PC_ALT_LEVEL_2

Unfortunately I don't know about any way how to do this in XKB syntax. So it leads to a whole set of options, one for each grp:*_shift. Or do you know some trick?

> Unfortunately I don't know about any way how to do this in XKB syntax. So it
> leads to a whole set of options, one for each grp:*_shift. Or do you know some
> trick?
You're right, the "left side" of the mapping is always keycode, not keysym. So it would be a set of options which defeats the purpose... :/

> Win+Shift+s gives 'Ы' but Shift+Win+s does Multi_key action - nothing is
printed and user is confused.
Actually, with your patch Win+Alt+s gives nothing, Alt+Win+s gives Multikey action. So it is not symmetrical anyway. What do you think?

(In reply to comment #5)
> > Win+Shift+s gives 'Ы' but Shift+Win+s does Multi_key action - nothing is
> printed and user is confused.
> Actually, with your patch Win+Alt+s gives nothing, Alt+Win+s gives Multikey
> action. So it is not symmetrical anyway. What do you think?

Yes, I know. The current state makes Mode_switch unusable for anyone, the only difference between me and the others is that I probably (and hopefully) found the root cause - for example watch the bug Bug 15406 which is, I believe, duplicate of this one.

So my idea was to think about use cases and find a definition working for those use cases (sorry for so long description):

1. people don't want to get a different result with same modifiers but pressed in the different order.

2. with Shift+key one probably wants Level2 variant of the key (typically upper-case letter for alphabetic characters). Then Shift+Mode_switch+key must do the same for the second group(=layout)

3. with Alt+key there is usually no symbol defined, it is used as Level1 of the key + modifier 'Alt' set (look to the Bug 15406 again that this was the workaround Dmitry Morozhnikov suggested). Typical usage then is to use this as a hot-key for some application (Alt+F for File menu etc.). Only A-Z0-9 chars are used as hot-keys, so it doesn't make any sence to press Alt-ы, for example, and the conclusion is that it doesn't make any sence to press Alt-Mode_switch-key at all.(*)

4. Just to confirm: Multi_key acts in similar way as dead-keys, not as shifts, so its usage is Multi_key,key1,key2 - not Multi_key+key1,key2. So Multi_key usage is not affected by the paragraph 3 above.

*): And keys defined with type=PC_ALT_LEVEL_2 are same in all groups, so, again, it doesn't make any sence to press Alt+Mode_switch+key.

Huh, I understand this was a LONG description but I hope that bot my idea and the reason why it doesn't break the compatibility are clear now. Plus you can see the (probably) same bug reported by someone other too.

> 1. people don't want to get a different result with same modifiers but pressed
> in the different order.
Actually, I am not 100% sure. For example, IIRC in some windows layout switcher there was a configuration where Alt+Shift switched to 1st layout, Shift+Alt - to the 2nd one. But in general, you're almost right:)

> 2. with Shift+key one probably wants Level2 variant of the key (typically
> upper-case letter for alphabetic characters). Then Shift+Mode_switch+key must
> do the same for the second group(=layout)
Well, for me it is not obvious. Since groups contain levels, I would expect Mode_switch+Shift+key to provide me with the 2nd level of the 2nd group. The other way around ... it is handy but not necessary (if we do not consider #1 as law of nature:).

> a hot-key for some application (Alt+F for File menu etc.). Only A-Z0-9 chars
> are used as hot-keys, so it doesn't make any sence to press Alt-ы, for
> example, and the conclusion is that it doesn't make any sence to press
> Alt-Mode_switch-key at all.(*)
Well, that is a bit issue per se. In Russia people DO want to press Alt-ы and expect "Alt-s" behaviour just because on the first group there is S (even though the current group is second, Russian, with ы). There are various bug reports (in gnome, mozilla, ...) about that. This gets especially odd when 2 groups are, say us and us(dvorak).
And usually it is handled by the application/toolkit. This typically happens when 2nd group is locked, not shifted, but my point it that (in case of correct application/toolkit) Alt+Mode_switch-s can be equal to Alt+s or Alt+ы (XKB-wise) - the behavior should not change.

> 4. Just to confirm: Multi_key acts in similar way as dead-keys, not as shifts,
> so its usage is Multi_key,key1,key2 - not Multi_key+key1,key2. So Multi_key
> usage is not affected by the paragraph 3 above.
I never actually used Multi myself (no need), but from a couple of tests I got similar impression (other people on the list can confirm or protest).

Actually, I would appreciate if other people on xkb maillist (especially the ones who actually use Multi key) would express their opinions on the subject.

(In reply to comment #7)
Firstly, all answers to all details :-)
> > 1. people don't want to get a different result with same modifiers but pressed
> > in the different order.
> Actually, I am not 100% sure. For example, IIRC in some windows layout switcher
> there was a configuration where Alt+Shift switched to 1st layout, Shift+Alt -
> to the 2nd one. But in general, you're almost right:)
> 
> > 2. with Shift+key one probably wants Level2 variant of the key (typically
> > upper-case letter for alphabetic characters). Then Shift+Mode_switch+key must
> > do the same for the second group(=layout)
> Well, for me it is not obvious. Since groups contain levels, I would expect
> Mode_switch+Shift+key to provide me with the 2nd level of the 2nd group. The
> other way around ... it is handy but not necessary (if we do not consider #1 as
> law of nature:).

:-) Yes, this is why I'm talking about practice, not any theoretical logic.  Because, theoretically, you're absolutely right. But in practice not - my experience says that #1 is true in real life.

> 
> > a hot-key for some application (Alt+F for File menu etc.). Only A-Z0-9 chars
> > are used as hot-keys, so it doesn't make any sence to press Alt-ы, for
> > example, and the conclusion is that it doesn't make any sence to press
> > Alt-Mode_switch-key at all.(*)
> Well, that is a bit issue per se. In Russia people DO want to press Alt-ы and
> expect "Alt-s" behaviour just because on the first group there is S (even

Yes. Typical problem with grouplock which disappears if you are using Mode_switch instead :-) Because, with layouts us,ru what could be the reason to press Alt-Win-s instead of Alt-s? Theoretically you are right with a pair of different latin layouts (i.e. qwerty+dvorak) but I still think this is not an issue for Mode_switch, it is the issue for grouplock only. Why would one press Alt+Win+f instead of Alt-u?? 

The only reason I can imagine now is if someone has a combination ru,us (ru as the first layout) and needs Mode_switch for every latin letter. But this looks like a theoretical construction, I can't imagine any real person doing so.

> Actually, I would appreciate if other people on xkb maillist (especially the
> ones who actually use Multi key) would express their opinions on the subject.

Sure, good idea. If there are people who actively use Mode_switch.
Because I worry we are talking about a very small group of people: how many people even know about Mode_switch? AFAIK people who don't know UCW layout know about grouplock only. So it is hard to decide what is usual if the group is so small - or am I wrong? Are there areas in the world where Mode_switch is more common? Can anyone say?

Then, I want to emphasize <em>we don't want to forbid Alt+Mode_switch</em>, the only problem we have is that it seems (with my level of xkb knowledge, which I feel shall be better :-)) there is a problem with modifiers resulting in the need of the decision that one of combinations Shift+Mode_switch or Alt+Mode_switch will have to depend on the order of modifiers pressed. And my opinion is, that if we don't know the solution for both, I choose Shift+Mode_switch as the prioritized one as it is (far more) frequent, I think.

So there are two questions:

1. is there any way how to solve both combinations? (something I can't see because of my limited xkb knowledge?)
2. if no, do you agree that uppercase letters in the second group are more frequently needed than Alt+<key from second group>?

> 1. is there any way how to solve both combinations? (something I can't see
> because of my limited xkb knowledge?)
I cannot invent that trick, I'm afraid.
> 2. if no, do you agree that uppercase letters in the second group are more
> frequently needed than Alt+<key from second group>?
In general - yes. But my voice is very humble here. I would love to hear from anyone who is actually using Multi_key...

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/12.