<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 23, 2015 at 11:38 AM, Kieran Bingham <span dir="ltr"><<a href="mailto:kieranbingham@gmail.com" target="_blank">kieranbingham@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> This is a very common request, usually for the opposite reason: to make a<br>
> modifier also produce a keysym. In particular it would allow Ctrl or AltGr<br>
> to act as a compose prefix, something a lot of plugins for Windows does,<br>
> while X (which invented the compose key) is forced to dedicate a key.<br>
> (compose is (I hope) actually done by the input method, which can in fact do<br>
> this handling of Ctrl, the problem is that it can't use the mapping of the<br>
> compose key, it has to actually use Ctrl, and thus it has to have a<br>
> different configuration file to control what key is the compose prefix than<br>
> the keyboard layout).<br>
><br>
> This can also make Windows style things like Alt moving the focus to the<br>
> menubar, or the Super key popping up a dialog while still acting like a<br>
> modifier. I know these work on Linux but they do so because the apps are<br>
> actually looking at the Alt or Super key to see if they are released. It<br>
> seems more consistent that these actually produce a "Move to menubar" or<br>
> "super menu" keysym, thus allowing keyboard layouts to move them around.<br>
<br>
</span>Yes - these are perfect examples. I guess you are saying that this is<br>
not currently<br>
handled by xkb, but by the desktop manager or UI toolkit?<br></blockquote><div><br></div><div>Yes. Currently the toolkit has the information "the Alt modifier moves the focus to the menubar". Rather than the more consistent "the Alt key has the MOVE_FOCUS_TO_MENUBAR keysym". This is somewhat annoying because what the user considers key assignments is done in different places. In reality it is more of a conceptual problem than practical one, as users rarely change such assignments.<br><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> And before you say "rollover" I am well aware of that. The toolkits handling<br>
> the Alt key are already dealing with this, and it is no excuse for<br>
> completely disabling functionality!. I think xkb could use the event<br>
> timestamps to detect this. Though it really sounds like that touch handling<br>
> stuff with all the fiddly timing and dependency on hardware details, so<br>
> maybe (yeah right) we could again consider moving keysym translation to<br>
> libinput and out of clients.<br>
<br>
<br>
</span>What's 'rollover' in this context?<br></blockquote><div><br></div><div>If a user types quickly they may not release the previous key fast enough and thus the release is after the press for the next key.<br><br></div><div>In your example a user may just be typing fast, and intending to type a space and then the letter 'a', but they are going quick enough that the space is still held down. Your keyboard would then type a semicolon when the user expected an 'a'.<br><br></div><div>Yes this is a problem, but it is not a reason to make it impossible for xkb to do this at all. However I believe that is the excuse being used for this lack of ability.<br><br></div><div>(normal solution is to apply complicated timing rules to detect if this is happening. Certainly xkb could do this, it gets timing information. I personally feel this is a complexity similar to the touch rules being done by libinput, therefore the entire decoding should be moved from clients to libinput, and Wayland clients would get events with the already-decoded keysyms attached to them. There is considerable dislike for this idea from the Wayland developers, though I am stumped why. My best guess is that it makes X11 emulation harder).<br><br></div></div></div></div>