Hi,<br><br>On Thursday, November 13, 2014, Giulio Camuffo <<a href="mailto:giuliocamuffo@gmail.com">giuliocamuffo@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2014-11-13 11:18 GMT+02:00 Daniel Stone <<a href="javascript:;" onclick="_e(event, 'cvml', 'daniel@fooishbar.org')">daniel@fooishbar.org</a>>:<br>
> Think about the case where pressing Alt on its own will focus the system<br>
> menu, but pressing Alt-F will raise the file menu directly. Let's say the<br>
> compositor has an Alt-F12 hotkey which triggers some action and then<br>
> immediately returns focus. We'll come back to the client with Alt held down,<br>
> and nothing else. When we come back, we do _not_ want the client to focus<br>
> the menu as if Alt was pressed normally. However, we _do_ want the client to<br>
> raise the file menu if F is then pressed (so, Alt+F). This exactly matches<br>
> the previous paragraph: update your internal state, but do not immediately<br>
> trigger any actions.<br>
<br>
But this should not be affected by this patch. The key binding just<br>
eats the F12, so the Alt is still being sent to the client.</blockquote><div><br></div><div>So we've introduced an inconsistency. It happens to mostly kind of work for modifiers, but that's luck of the draw.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> We can see exactly one outlier here, doing the exactly wrong thing, which is<br>
> XWayland. So it stands to reason that XWayland should be fixed: changing the<br>
> others would introduce massive inconsistencies depending on whether your<br>
> compositor is native or nested, which makes ~no sense.<br>
<br>
I perfectly agree XWayland is broken here. But i don't see how this<br>
patch breaks weston.</blockquote><div><br></div><div>By introducing an inconsistency for, as far as I can see, no reason. That it mostly happens to work is great, but that's luck rather than design.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> I think the fix makes Weston act _less_ consistently, especially when you<br>
> consider how it behaves when it's nested. If Weston nested under Wayland<br>
> behaves differently to DRM, that's proof that our model is broken.<br>
<br>
But consider this case: There is a Alt+X compositor binding which<br>
triggers something, without changing the focus. Then the client has a<br>
Alt+X+Y binding. When pressing Alt+X the X is eaten by the compositor,<br>
so trying to press also Y to trigger the client binding will have no<br>
effect, because the client will actually see just Alt+Y. Without this<br>
patch, if the Alt+X compositor binding was to instead switch the focus<br>
to the client, the Alt+X+Y binding would work, because the client sees<br>
the X too. Now it doesn't, as it doesn't without switching the focus.<br>
This is where it is more consistent.<br>
</blockquote><div><br></div><div>But this is just a client issue, and nothing in sending the full keys array precludes this working.</div><div><br></div><div>If Alt+X is a modifier (i.e. any time Alt+X is held, pressing Y triggers the shortcut), then the client can use the keys array to notice this, and ensure the shortcut is fired.</div><div><br></div><div>If Alt+(X+Y) is a cumulative shortcut, then the client knows from seeing X in the enter array but not a key event, that it must wait for a release on X before it arms the shortcut for Y.</div><div><br></div><div>In both cases, no problem. If we suppress X in the key-down array, we break the first case, and in the second case, we send the client a release for a key it's never seen. IOW, we introduce enormous inconsistencies in the key book-keeping. As there's ~nothing more infuriating than broken key/button state handling, and it's already relatively complicated code, I don't see how any good can come out of making it easier to screw up for pretty much no gain.</div><div><br></div><div>Given the above, and the possibility of making XWayland do the right thing, I just can't see how this patch improves the status quo (pre-this-patch), given the enormous downsides.</div><div><br></div><div>Cheers,</div><div>Daniel </div>