What I meant was:
If in fact the mouse is pointing at the same surface that receives the
keystroke (and then creates the popup menu) there is no problem, as that
client knows the relative position of the mouse verses that surface and
can therefore use relative positioning to it to place the popup menu.
Assuming there is no problem with child windows raising their parent (if
there is this is a bug that has to be fixed in the compositor) then the
client could also do this if the mouse is pointing to any one of it's
surfaces.
Where this gets difficult is if the desired behavior on the keystroke is
to "grab" the mouse and popup the menu whereever it happens to be. I am
not sure if wayland should allow this, and whether there are clients
that expect this to work, but I can't see any way of doing this that
does not involve a round trip: message from client to server to grab the
mouse, response from the server after the grab saying where the mouse is
relative to the surface, and the client creating a window and
positioning it using this relative position.
On 07/01/2014 03:39 PM, Fabrice Rey wrote:
> "When the keyboard and mouse focus are the same surface then relative
coordinates for the popup can be used"
There is no window having focus here. Or maybe there is, but it's not
the surface of the "circular menu", which is hidden, and only appears
when pressing a shortkey (about global shortkeys, that's another point
I'll come back to later, let's assume we can have global shortkeys on
Wayland for now).
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
