change allows a restart to trigger proper teardown first, even though
teardown is not (yet) complete.
After some discussion with oga@nicotinebsd.org regarding a more
complicated version/idea.
used for focus events, but rather the timestamp of the generated event.
Track the last event timestamp and send it down for a WM_TAKE_FOCUS
ClientMessage. I suspect we should do this for clients that don't
announce this Atom as well, though the raciness gets us into a bind.
Solves focus order issue since WM_TAKE_FOCUS; fix verified by sthen@
ok sthen@
and unmanage the client if we're not hidden (basically if NormalState)
during an UnmapNotify event.
Resolves an issue with mplayer going fullscreen while not using NetWM
hints; behaviour regression reported by Ido Admon.
worked (and no one complained!). While it's fairly easy to fix, users
should be using keysym names and not keycodes.
Discussed at length months ago with todd@, matthieu@ and Owain.
client_leave() served no real purpose, likewise no reason to handle
LeaveNotify events since an EnterNotify will process the next active
client (and we don't have anything important to process anyway), so
xev_handle_leavenotify() goes as well. Allows a simplification of
client_mtf() and client_cycle_leave() for clarity. While here, unify a
few client_current() checks.
No intended behaviour change.
queue check (removing the need for a server grab/ungrab) - if the client
is going away, let it fall all the way through to a DestroyNotify event.
There's no longer a need for us to manually destroy a client ourselves
(removing yet another server grab/ungrab). Instead, when the
UnmapNotify event is synthetic, simply set the state to Withdrawn (as
per ICCCM), else Iconic (in our case 'hidden').
Verified with test case from the 2009 race which was the original reason
for r1.35 of event.c.
triggering event was unmap (with pending destroy) log destroy; we only
need to grab/ungrab the server lock, set WithdrawnState and
XRemoveFromSaveSet clients coming from an unmap event - doing so for
clients coming from destroy are already gone, hence we generate errors.
to grab keys in keybindingq. we don't need to ungrab/grab on every
addition to the queue, just once with a complete keybindingq; simplify
grabbing keys per screen (during init) and during a MappingNotify.
while here, change conf_grab_{kbd,mouse} to require only a Window.
don't need to pass down the new values to screen_update_geometry(); so
just read the width/height values directly for both uses of
screen_update_geometry(). prep for further changes in this area.
1.52), not realising that the previous (less efficient) fix had already
been commited (rev 1.50).
Had this in my tree for ages to remove the previous code. Effectively
reverts rev 1.50.
ok okan@
Requested by Christian Neukirchen last august. He provided a patch but the one I
wrote was significantly simpler (1 - 2 + in the whole diff).
makes sense to okan@.
says that a pager can change the property at any time (most need a
clientmessage). So deal with property updates.
Needed to shuffle some of the other code around since we can't just use
shortcut_to_name[] everywhere now.
ok okan@
remove screen_current() it was utterly bogus when nscreens > 1.
pass a fake client_ctx in the case where there's no client and the
kbfunc or mousefunc doesn't need a real one, it just contains the
current screen, modify these functions so that they pass down the screen
context to their callees.
make groups per screen, it's the only way it makes sense in this regard.
ok okan@.
every other window manager since twm.
The event layer is very nice, very shiny, very flexible, and very much
underutilised. We don't need any of those shiny features so it's
probably better to earn ourselves 1k smaller text size instead.
ok todd@, okan@
times you'd end up losing clients (thinking they had gone away).
From the ICCCM (which should not be read without a stiff drink in hand,
I made this mistake so you don't have to): to request a window to be
withdrawn one should send a synthetic UnmapRequest event when iconified.
To request iconification one should just unmap the window. The ICCM
further recommends that the synthetic event should just be taken as a
cue to withdraw, to deal with legacy clients. Taking a hint from this,
rework xev_handle_unmaprequest to correctly detect these situations. A
Withdrawn window may come back anywhere, even as a subwindow of
something else, so the correct way to handle this state is to forget it
ever existed.
While i'm here, kill a dumb attempt to notice this in client_delete, and
nuke the very unnecessary arguments.
Todd confirmed this fixes the `race'.
ok todd@, ok ok okan@
to push attributes around, so things get a lot simplier, while fixing a
few issues in the meantime; original suggestion by Edd Barrett many many
moons ago.
annoying window placement and race, found in c2k8 by todd, fix by oga!
lots of feedback from todd and oga - thanks!
"commit that bad boy" oga@
reconfiguration events and change our sizes depending on that. We also detect
the xinerama screens for maximize, vertmaximize and initial window placement.
This could be improved by automatically resizing maximized windows when
the screen resolution changes and by moving windows that would be hidden
into visible space. Said changes will come shortly.
Tested by many. matthieu@ didn't oppose.
Implement a handler for the MappingEvent, meaning that the keymap has changed.
When this happens, ungrab all bindings, update the map, and regrab.
Fixes the problem where some keybindings wouldn't work under non us or
uk keymaps (especially the .fr map, it seems). Issue noticed by
ajacoutot@, ratchov@, and a few people on misc. Based on an initial diff
from ratchov@.
ok okan.
The problem that's causing us to lose windows is that rapid hiding and
unhiding causes a backlog of X events, so we lose track of client state,
and delete cc->pwin when we should not. A proper fix will arrive when it's been
worked out.
