| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| |
| |
| |
| | |
link to the group queue for each screen.
|
|\| |
|
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| | |
NET_DESKTOP_NAMES, merge the helper into xu_ewmh_net_desktop_names,
where we actually set the property.
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
place that we use highstack, replace that usage with a local variable
(for now until stacking is done properly).
|
| |
| |
| |
| |
| |
| |
| | |
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().
|
|\| |
|
| |\
| | |
| | |
| | |
| | | |
the hidden state on the group; important to know group hidden state
after a re-exec or restart of cwm (as easily seen in group menu).
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
group 0 (nogroup); solves problem initially discovered by oga@nicotinebsd with
tint2. A clientmessage *after* client creation already handles this case.
Go further and assign every client to a group; in non-sticky mode, group 0
(nogroup) and sticky mode, the active group. In both cases, autogroup will
override the group assignment. Removing a group from a client always places
the client back into group 0 (nogroup). Autogroup can also assign a client to
group 0 (nogroup) to keep a client always visible (unless of course one opts to
hide all clients).
|
|\| | |
|
| | |
| | |
| | |
| | | |
sanity check by oga@nicotinebsd
|
|\| | |
|
| | |
| | |
| | |
| | | |
path; from Tiago Cunha.
|
|\| | |
|
| | | |
|
|\| | |
|
| | | |
|
|\| | |
|
| | | |
|
|\| | |
|
| | |
| | |
| | |
| | | |
for gathering Atoms.
|
|\| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | | |
overflows; from Tiago Cunha
|
|\| | |
|
| | | |
|
|\| | |
|
| | | |
|
| | | |
|
|\| | |
|
| | | |
|
| | | |
|
|\| | |
|
| | | |
|
|\| | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
change noticed by Thomas Pfaff and diagnosis why we need to
group_setactive in this case by Alexander Polakov. replace XXX with
a useful comment.
|
| | |
| | |
| | |
| | |
| | |
| | | |
numbering re-work; discovered the hard way by sthen@.
ok sthen@
|
|\| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
(in sticky or non-stick mode), regardless of existing clients assigned
to that group; oga marked this bit XXX in -r1.34 for it didn't seem make
sense then either.
pulled from a diff from from Alexander Polakov.
|
| | |
| | |
| | |
| | |
| | |
| | | |
note that a re-exec of cwm will not rewrite the group number atom of
*existing* clients, so they will remain off-by-one until each client has
its atom updated, or of course a restart of X.
|
|\| | |
|