Comment 36 for bug 36812

> To make this happen, the event should be triggered following step 3.
>.
>.
> So, basically what needed to be done is whenever a key is pressed, key
> combination should be matched against the current pressed keys, and if a
> combination is met exactly, we should only set a flag for this combination -
> and not actually fire the event.
> Whenever a key is released, this flag is checked - if the flag was set, the
> event shoud be fired and the flag should be cleared.
>.
>.
> I think this is good enough for 99% of the cases.

Good idea with the flag, and you are probably right that your solution would solve 99% of the cases (since lot of people affected by this probably use just two layouts - US and their national one - at least that is my situation).

Anyway I would be definitely for incorporating the "recency-awareness" into the switching of keyboard layouts. It would be very handy in the case when there is need to switch among more than two layouts.

I know I'm straying quite a bit from the original problem now, since this is definitely a request for extension, but I think it's still in close relation, so let me explain the idea in more detail.

--- First introduce some shorthands

<key> down = press <key> and hold it down
<key> up = release <key>
<key> hit = press <key> and immediately release it

--- What do I mean by "recency-aware" switching and why is it a good idea

Basically it's the type of switching that is used for switching among windows in XFCE/GNOME/KDE, so let's first describe how that works. For example, let's open four applications in say XFCE - first app1, then app2, then app3 and finally app4. By that, subsequently app1 app2 app3 and app4 gets focused (i presume that when the app is opened, it gathers focus). So now app4 is focused. Suppose we want to switch to app2. What one can do is:

1) Alt down
2) Tab down - now a list of applications appears, showing the applications in this order: app4, app3(selected), app2, app1 - it's the order in which they had been lastly focused
3) Tab up
4) Tab down - now app2 gets selected in the applist
5) Tab up
6) Alt up - this release triggers the actual switch, so applist disappears and app2 gets focused; also, the applist gets reordered (internally) - the apps in it are now in this sequence: app2 (currently=most recently focused), app4, app3, app1 (focused longest time ago)

Now suppose we want to switch back from app2 to app4 (typical scenario: app2 is an editor in which one edits a webpage and app4 is a web browser used for testing that page). With recency-aware applist, this can be done easily, thanks to the clever rearrangement of apps in it:

1) Alt down
2) Tab down - list of application appears: app2, app4(selected), app3, app1
3) Tab up
4) Alt up - app4 gets focused

If the list didn't get rearranged (and was still app4,app3,app2,app1) one would need to hit tab twice to get back to app4 (assuming wrap arround). But with recency awareness, it's just "down Alt + hit Tab + up Alt" et voila.

Compare this to e.g. tab switching in Firefox which, by default, is just rudimentary; no recency awareness there. Ctrl+Tab is just "switch one tab to the right", Ctrl+Shift+Tab "switch one tab to the left". Switching back and forth between a pair of tabs, using only keyboard, is not easily accomplished, especially if the tabs aren't next to each other. And even if they are next to each other, each time you switch you have to think about "am I now in the left or in the right tab? should I switch to the right or to the left?" With recency-awareness, it would be just "down Ctrl, hit Tab, up Ctrl" to switch back and forth. I don't want to critize Firefox here. I just want to illustrate how handy the recency awareness in switching can be.

--- Back to recency-aware layout switching - explanation by example

It's basically a direct analogy of recency-aware window switching, with one subtlety - the (optional) dialog appears after the first release of Shift, not the first press.

Let's have four keyboard layouts set in the X server - 'us','cz','de','fr' (ordered from most recently used/locked to the longest-ago locked); i.e. the 'us' layout is the one currently locked, and 'fr' has not been used for the longest time. Now let's say we want to switch to the 'fr' layout. It would work in this way:

1) Alt down
2) Shift down
3) Shift up - now the actual layout switch would begin; in cooperation with desktop environment, some dialog window should (optionally) also appear, displaying the (in our case four) available layouts, with the most recently used layout ('us') on the first place, and the second layout ('cz') selected.
schematically: [ us, *cz, de, fr ] - selection indicated by asterisk here

It is important that the dialog for switching should appear only by now, after the first release of Shift. It could be confusing if the dialog appeared after step 2) since Alt down followed by Shift down can be just beginning of some Alt+Shift+something shorcut (e.g. Alt+Shift+Tab).

4) Shift down - now the 'de' would get selected: [ us, cz, *de, fr ]

The cycling in the list is now triggered by the press, since we now presume that the user wants to switch layouts, it's ok now to have feedback on press.

5) Shift up - nothing happens, 'de' stays selected
6) Shift down - 'fr' gets selected: [ us, cz, de, *fr ]
7) Shift up - nothing happens, 'fr' stays selected

Note: up until now, no actual change of the layout has occured! It's just the selection of the layout we intend to lock that takes place so far. Shift is used to walk (or, rather, cycle) through the list of available layouts as Tab is used to cycle through the list of available windows. The selection of the new layout can be cancelled by pressing e.g. "esc" (similarly as the switching of window can be cancelled by "esc").

8) Alt up - only this release triggers the actual locking of the new, in our case 'fr' layout. The list of layouts disappears, internally it gets rearranged to this state: 'fr', 'us', 'cz', 'de'.

Subsequently with "down Alt + hit Shift + up Alt" one could switch back to 'us' layout etc.

So this is my proposal for keyboard layout switch. It requires changes in the XKB and also in the desktop environments (to display the layout selection window), but the result would be well worth the effort IMO.

Regards,
Adam