| Age | Commit message (Collapse) | Author |
|
|
|
|
|
go away entirely soon.
|
|
|
|
|
|
|
|
other action above it that will change where focus can end up
|
|
|
|
|
|
docbook-to-man
|
|
|
|
from the FocusOut events
|
|
|
|
for mouse focus people.
|
|
|
|
same layer
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
states appear. better handling of focusin's on clients that don't exist?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
in the NETWM spec yet, but will be shortly.
|
|
|
|
when a focusin comes for an invalid target, set that focus has wandered off, so
that when the focusout comes in afterwards we can react accordingly
|
|
|
|
|
|
such that this would happen, then kill the interactive grab before moving
focus.
this is to avoid NotifyWhileGrabbed FocusOut's
|
|
destroy_notify which is really what it is, and is more consistant now that there are 2 notifies
|
|
each case.
|
|
want to know about it - also if the window gets hidden for some other reason, we also want to know about it.
add a notifier for windows being hidden, and use that instead - it handles both cases.
|