- no reason for pointer movement and window movement and resizing
sections that just describe default key bindings
- key bindings are for all search and exec dialogs, not just for windows
- adding missing bindings
- normalize and wordsmith
- re-order sections according to mdoc(7)
feedback and ok from jmc@
from re-hiding on restart due to flag toggling (note that this is ripe
for re-vamping). Behavior only observed on restarts.
Problem found by, and initial patch from, Henri Kemppainen (thanks!),
though ever so slightly different one applied.
Don't allow embedded nul characters in strings.
Fixes a pfctl crash with an anchor name containing
an embedded nul found with the afl fuzzer.
pfctl parse.y patch from and ok deraadt@
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.
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().
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).
clients) directly into client_init, performing the X roundtrip only
once. With the previous change in maprequest, this moves decision making
into one place for creating new clients.
original idea (with now-outdated patch) from Thomas Adam. Since we now
report where errors exist, this now makes more sense. Expand a bit on
config file parsing in the cwm(1).
Discussed with a few, including sthen; ok sthen.
config parse (and use conf_cmd_add to populate defaults); based on a
discussion with Tiago Cunha. While this looks ugly, there are likely
some other changes here to come.
then the window should appear on all desktops, which in our case is
assigned to group 0. Found to fix stalonetray due to the non-ewmh aware
range checking in group_movetogroup(); from Thomas Adam.
This is useless when searching for windows launched via the ssh command
menu; supply a more useful title: '[ssh] <hostname>'.
Idea from todd@, ok todd@
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.
- make conf_bind_kbd return error on non-matches to match what
conf_bind_mouse does.
- rename some variables while here for clarity.
- constify bind and cmd.
from Tiago Cunha.
Since we already have a form of 'maximize', we need to differentiate
between 'maximize' and the new 'fullscreen' mode. The 'maximize' mode
will continue to honor gap but now *retains* the border, matching the
'vert/horz maximize' behaviour. The new 'fullscreen' mode supports and
follows the _NET_WM_STATE_FULLSCREEN hint, allowing the client perform
additional window modifications; in this mode, cwm(1) will *ignore* gap,
remove borders and freeze(move/resize) the client. Additionally,
'fullscreen' mode will remember various combinations of previous states.
* default keybinding changes: CM-f 'fullscreen', CM-m 'maximize' (re-map
as desired).
Positive feedback from a few, testing and ok sthen@
ewmh hint; urgencyborder is configurable. The urgency flag will stick,
even while on a client in a non-viewable group, until the client
receives focus (where the border is reset). Initial diff from Thomas
Adam with some changes/enhancements from me.
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.
XSetInputFocus() for clients that have the InputHint; latter fix
discovered by Valery Masiutsin with a PoC patch - solves keyboard input
focus loss for java apps.
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.
BadValue) when the modifier is already AnyModifier . Instead alter
xu_btn_ungrab() to ungrab AnyButton/AnyModifier and call it only when a
client is coming into focus in client_setactive(), instead of iterating
over ignore mods - matches how we handle key grabs.
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.
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.
