there's a window of time where an expose or enternotify event will get
generated for a lower client; use a hammer and drain events after keyboard
move/resize, until such a time that cwm doesn't warp the pointer. Behavior
noticed by kn.
ok kn@
which one may configure (wm <name> <path_and_args>) (and choose) specific
window managers to replace the running one. 'wm cwm cwm' is included by
default.
No objections and seems sensible to sthen.
into the keyrelease event, only performing what's actually needed for each;
should result in much fewer events against keyreleases. No intended behaviour
change.
Additionally, like we do for group membership, grab the keyboard only when
required for cycling.
re-proposed by Julien Steinhauser with an updated diff. Apparently this was in
the original calmnwm.
However, expand the original idea and let clients 'snap' to edges instead,
neatly allowing key bindings that snap to adjacent edges (i.e. corners) as
well. No default bindings assigned.
*and* window.) of mousefunc.c. When a client destroys itself while we are
moving or resizing it, XWindowEvent() blocks. Found the hard way by Anton
Lazarov, and Lea°hNeukirchen found the right bit to revert - thanks! Reverting
since the reason to switch from XMaskEvent was unclear.
the previous behaviour of 'menu-window'. 'menu-window' becomes the default
binding; use 'bind-mouse "1" menu-window-hidden' to restore old behaviour for
those who prefer.
OK sthen@ (long long time ago on a different version)
client_ctx in keypress and buttonpress event handlers; pass appropriate *ctx's
based on context.
While here, limit some globals, replace defines with appropriate variables and
fix some naming.
key press. This allows to remove a few hacks to duplicate functions only
for behaviour changes; now differing behaviours are pushed down to the
callback. Also will allow for previously unavailable actions to be bind-able
down the road.
mousefunc_menu_{client,cmd,group} into the respective
kbfunc_menu_{client,cmd,group} functions; simply pass a flag down from
config denoting mouse action behaviour.
got nothing to do with clients, thus doing flags work causes lots of
waste and almost useless jumpy pointer movements; while here, split out
move and resize since they share almost no code, just like mouse client
move/resize; factor out amount and factor. Still wonder why this is
here, but it works now.
fix for a regression is found; this bug has been around for a long time
it seems, but this change exposed it. Likely need to track clients in to
and out of regions.