<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 28, 2015 at 12:37 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
wl_seat are not meant to model possible targets, they are collection of<br>
foci related to aggregates of input devices. If the compositor needs to<br>
re-route a certain key to something else than the current wl_keyboard<br>
focus, it is fairly easy to temporarily switch the focus.<br></blockquote><div><br></div><div>Exactly! Therefore if a new type of foci is needed, it needs to be added to the seat! Not saying you need a new seat. If that was true, why not just make the pointer and keyboard focus two different seats???<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> I am not clear on how the client with the pointer focus can figure out what<br>
> modifiers are down however. But if the remote has modifiers I think users<br>
> expect them to act global, ie holding the Shift on the remote is the same<br>
> as holding Shift on the keyboard.<br>
<br>
</span>This scenario breaks your proposal of abusing the wl_pointer device type.<br></blockquote><div><br></div><div>No, it breaks the CURRENT scheme. If the pointer focus is a different client from the keyboard focus, the pointer focus client cannot tell what shift keys (or other keys) are held down when the user clicks the mouse. Lots of UI designs require this information.<br><br></div><div>I am rather alarmed to hear that this is broken right now, I thought for sure I was just not finding the method that modifier change events were sent to clients other than the keyboard focus... <br><br></div></div></div></div>