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.
region_find() which no longer needs to recalculate gap each time
a client (or menu) is created or altered. If no RandR, fall back
to display dimensions while building regions instead of during
execution.
eliminate from ButtonRelease); further limits the amount of work done
outside the threshold, notably mousefunc_sweep_calc,
screen_find_xinerama and client_snapcalc.
this check to decide if a group is virtually empty. Rationale: if a
group contains *only* 'sticky' clients, it should be skipped while
cycling through groups. Apply similar logic to the group menu.
Based on an idea from phessler@, who also tested another version.
global Clientq and place it inside screen_ctx since every client belongs
to a screen, then use the same per screen clientq to track stacking
order (the sole reason for mruq).
to having to manage an array outside in screen_ctx for group names and
shortcuts. Simplifies (and moves bits for) reading, and constructing
data for, EWMH's _NET_DESKTOP_NAMES.
symantics between cwm groups and ewmh got in the way. Ensure a client
that wants to be in nogroup stays in nogroup (thus stays in view), even
when (re)reading NET_WM_DESKTOP. Paritially reverts patchset 644
(2014-02-07 13:09 PST) which deals with a NULL cc->group. All to be
revisited when NET_WM_STATE_STICKY hits cwm.
Reported by many; testing and ok phessler.
the cc->pwin days - don't redraw on every unhide, resize, and mouse
move/resize Expose event (note, all Expose events trigger a redraw
anyway).
Tested with some finicky X apps I could think of, though I'm sure others
will find more - if so, and they 'lose' the border, please report!
event on the screen's root window, there's no need to pass down the
entire XButtonEvent event, at least to group_menu(), the only callback
which takes an argument at this point; instead use the already populated
screen.
