Rafael Antognolli wrote:
So, I added "activated" and "deactivated" events, that the compositor can use
to inform clients what they are. And there's a take_focus request
Shouldn't that be called a "take_active" request?
I can think of scenarios where it would be useful to get the keyboard
focus but not activation. I believe there is no need to support this
initially, as *becoming* active can always mean the client gets the
focus. But there may need to be a way for a client to take_focus without
becoming active.
The scenarios I see this being useful:
To not activate on a drag & drop in point-to-type: a client could send
only a "take_focus" when the mouse enters it. It does an activate only
on a mouse-click or keystroke that does *not* start a drag.
To support OS/X style menubars with point-to-type or when click does not
raise surfaces: clients might take the key focus on enter/click, but not
activate until the user types a keystroke. Thus the user can move the
mouse to the menubar in a point-to-type system without the menubar
changing, and can click in background windows without the menubar changing.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
