| Age | Commit message (Collapse) | Author |
|---|
|
At some point I wanted to support naming virtual desktops, but that
never materialized and I don't find myself wishing it was there.
|
|
This adds a direction parameter to vwm_desktop_next{_mru}() and
vwm_win_focus_next(), deprecating _prev() variants in favor of
a vwm_direction_t parameter.
XK_r has been wired up as a modifier for reversing the direction
of actions like Mod1+Tab (window next MRU cycle) and Mod1+Space
(desktop next MRU cycle). So now if you overshoot, simply hold
the "r" key and repeat the operation to go back, much like how
Shift is often used for reversing alt+tab in i.e. Windows.
|
|
|
|
When the shelf isn't the currently focused context but the focus
next is relative to the focus context the mapping manipulation
shouldn't be performed.
This would cause unexpected appearance of shelved windows in a
virtual desktop should a shelved window become invisibly unmanaged.
Simple way to repro is to shelf an mplayer window. When the movie
finishes, if you're on a desktop, out of nowhere the next shelved
window appears but you're not supposed to be looking at the shelf.
A simple visit to the shelf then back to the desktop would undo the
anomaly, but it's trivial to fix - hell there was already a FIXME/TODO
sitting there.
|
|
|
|
Previously only windows fitting the screen dimensions @ assimilate
would become automagically "allscreened". Newer mplayer seems to
break this heuristic, so expand the application of the heuristic
to include configure requests as well.
|
|
Use VWM_TRACE_WIN() and add a trace for when we try manage an xwin.
|
|
vwm_win_focus() previously simultaneously told the X server to set the
input focus on the window (if mapped) and set the internal vwm state of
the window to focused.
These are really two separate operations:
1. request the X server to focus the window
2. change vwm's concept of the currently focused window
Since clients can call XSetInputFocus() as well, there's need for doing
step 2 discretely in response to FocusIn events.
Nothing is functionally different after this commit, it just exposes
step 2 as a separate vwm_win_set_focused() function for a future commit
to leverage in handling of FocusIn events.
|
|
|
|
|
|
Rather than setting this configuring flag for the sake of
vwm_screen_is_empty() to ignore, simply supply the xwin to ignore if
desired.
|
|
|
|
|
|
|
|
In the course of applying the new style over the rest of the code I
decided it's obnoxiouos and prefer the old way of indenting the cases
one level from the switch. I know it wastes horizontal space and can
see the value of flattening the cases with the switch, but once you
start having variables at the start of the switch body, and blocked
cases, it just starts becoming quite unattractive without the indentation.
|
|
Eliminate some 0/NULL initializations.
|
|
This member reflects if the window is mapped from the client's perspective,
not necessarily if the window is currently mapped (since vwm maps and unmaps
windows the client has mapped in the course of providing virtual desktops)
Changing the name for better clarity, since it's a bit ambiguous as-is.
|
|
Long overdue tidying of the map request handling.
This moves all the window classifying and placement stuff into a separate
helper, adding a call to that in vwm_win_manage_xwin(), where this always
belonged.
The map request handling now just manages windows that aren't already
managed, then lets the usual "is this window mapped?" logic filter the
map request.
This should fix a lingering bug where a window on the unfocused desktop
would become spuriously visible if the client mapped it. Firefox started
doing this recently when a page finished loading.
|
|
We can assume (vwm->focused_desktop != NULL), the initial desktop
is created early in startup and the last one can't be destroyed.
|
|
|
|
I'm no longer fond of combining one-line conditional statements on
the same line as their conditional expression.
|
|
|
|
Long overdue house cleaning.
The addition of compositing/monitoring overlays in vwm3 pushed vwm well past
what is a reasonable size for a simple thousand line file. This is a first
step towards restoring sanity in the code, but no behavioral differences are
intended, this is mostly just shuffling around and organizing code.
I expect some performance regressions initially, follow-on commits will make
more improvements to that end as the dust settles.
|
