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.
client to 'stick' to all desktops (ewmh speak) or groups - this
currently has the same affect as setting a client's group to 'nogroup',
with the exception that the client can also be in a group, so when
un-sticking, the client will go back to its original group/desktop.
group_show() and group_hide() are not the only ways a group can change
state - if all clients in a group are either hidden or unhidden, then
that group's state should change, as well as the various EWMH ways.
Instead of trying to keep track in a wide variety of places, simply
query the clients in a group before needing to take action based on the
group's state. Solves long standing confusion of when a group is hidden
or not.
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.
since nhidden wasn't incremented nor decremeted in all the right places,
thus confusing matters. We don't need to carry a count around, so just
use a local variable in the one place we need one to supply
XRestackWindows().
/etc/X11/app-defaults stays 1st in the libXt search path so, people
and ports can put customized versions there if needed.
If you didn't customize the versions in /etc/X11/app-defaults, they
should be removed to avoid future issues when one file changes.
discussed at g2k14 and ok ajacoutot@
