| Age | Commit message (Collapse) | Author |
|---|
|
It's really only necessary to have 0-9, and brown is both
ugly and too similar to magenta
|
|
This makes vmon exit more cooperatively when window managers kindly
ask it to with a message rather than requiring XKillClient().
|
|
Cosmetic change, the plain truncation would occasionally result in
unexpected Hz values in the charts like 59Hz particularly using
vmon w/arbitrary --hertz values.
|
|
This is unfortunately a bit of a large commit, but it's at least
pretty much all on-topic for the generalized "contexts" feature.
Rather than waste time trying to split this further into smaller
commits, I'm just landing it as-is, now that I've lived with the
interaction model long enough to not completely hate it.
I fully expect to revisit this in the future. One TODO item in
particular I'd like to note is "sending" windows to contexts
always creates a new virtual desktop for the sent window in the
destination context. What should really happen is the
destination context should be checked for an empty desktop, and a
new desktop created only when there isn't an empty one to be
reused for receiving the sent window. Note this only affects
non-migrate sends, as migrates (modified by Shift) explicitly use
the existing focused desktop at the destination context.
See the README for more information on how contexts work and
what's different about the interaction model. It's fairly
minimal, most of what you already know how to do should keep
working as-is. The only oddity would be Mos1-s no longer
"shelves" windows, it's now a modifier to turn "migrates" into
"sends", and by itself is a noop now.
Colors used for contexts haven't been refined and are enumerated
in src/context_colors.def.
|
|
preparatory commit for generalized contexts replacing the shelf
|
|
minor ergonomic improvement; enables plain wrapping of creates or
other relevant object pointers with _mru() calls without
requiring an intermediate storage variable.
|
|
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.
|
|
Preparations for adding support for reversing {window,desktop}
list traversal directions. A subsequent commit will introduce a
direction flag of this type to the relevant functions.
|
|
The code is still quite messy, just some minor cleanups.
|
|
This was an experimental thing that isn't applicable to vwm, and will
only become less relevant as time progresses if libvmon receives some
attention.
|
|
There's an optimization where the search start pointer is
advanced on matches, to resume searching from the last matched
position. The assumption is that the in-memory list order and
the order coming out of the proc file will align.
Except using the standard list iterator, this would treat the
list head @ &proc->children as just another node in the list.
In the unlikely case where &proc->children treated as a siblings
member in a vmon_proc_t actually resulted in contents lining up
as a match, the generation update would scribble over part of
the parent pointer member, making things crashy when the parent
was dereferenced later in the fuction.
This commit just makes it skip over the &proc->children node if
encountered, just like in proc_follow_threads().
Hopefully this eliminates the remaining very rare vwm crashes
that occur during big parallel builds of the kernel or systemd.
|
|
Cleanup previous commit that littered MIN length clamping everywhere
%n was being used w/snprintf. Removed the %n usage altogether and
just clamps the return value out of snprintf to the buffer size minus
one for the null terminator.
The standard C library has such awful warts :/
|
|
It appears I overlooked that %n returns the length that would have
been printed regardless of the destination buffer size, not what
was actually written. The man page is misleading here:
n The number of characters written so far is stored into the
integer pointed to by the corresponding argument. That
argument shall be an int *, or variant whose size matches
the (optionally) supplied integer length modifier. No argu‐
ment is converted. (This specifier is not supported by the
bionic C library.) The behavior is undefined if the conver‐
sion specification includes any flags, a field width, or a
precision.
In testing, it isn't the count of what's actually written. It's
oblivious of truncated output scenarios where the output buffer has
been exhausted before reaching the %n. The man page should be
clarified here.
This commit does the simplest thing and simply clamps the length to
the destination buffer - 1 (for the \0). %n is being used to avoid
needing an strlen() in this somewhat hot path, but it might make
sense to instead use the snprintf return value similarly clamped
instead of %n since %n isn't doing what was expected.
|
|
|
|
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.
|
|
|
|
|
|
height = 2560 /3 = 853
while ( height -= 2) { // never hits 0
...
}
|
|
This loop assumed ancestor->parent was !NULL, and that's not necessarily
always true. Due to these circular linked lists from the kernel's
list.h, they're not simply NULL delimited and we need the pointer to the
actual head to detect the end of the list. In libvmon, the head for the
siblings list is either the parent proc's children member, or the
processes member of the vmon struct. It may be more elegant to switch
to always having a root proc in libvmon, even if it's just synthetic,
for simplifying this crap. But for now, just determine which head is
relevant and check against it for loop termination.
Under some heavy parallel kernel compilations I was seeing occasional
vwm segfaults, and the addr2line of the ip in dmesg mapped to this
particular loop. I'm assuming the ancestor walk landed on a top-level
process and then this sibling detection tried dereferencing the
top-level proc's NULL parent and boom, segfault.
|
|
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.
|
|
Adds VWM_SCREEN_REL_RECT so a screen can be located without a
formal xwin, just supply the x,y,width,height.
|
|
Use VWM_TRACE_WIN() and add a trace for when we try manage an xwin.
|
|
|
|
|
|
|
|
Some programs call XSetInputFocus(), so we should select
FocusChangeEvent and handle FocusIn events, calling vwm_win_set_focus()
when appropriate.
It's rare, but SDL2 programs in particular seem to do this and vwm gets
in a pretty annoying state when it does occur. This change should
improve the situation.
|
|
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.
|
|
|
|
Currently vwm doesn't notice when something else takes the input focus.
In some situations, this can leave a desktop without any focused
windows, and no way to focus one because the only window is already
focused as far as vwm knows.
As a stop-gap solution, remove the !focused condition to the
focus-on-window-click block. This way one can always force a window to
be focused by simply mod-clicking the window.
|
|
|
|
Rather than setting this configuring flag for the sake of
vwm_screen_is_empty() to ignore, simply supply the xwin to ignore if
desired.
|
|
|
|
This was mixed up a bit in the cleanups... charts of !width represent the
uninitialized charts, so don't copy or free them instead of inhibiting
just the copy.
|
|
`make tags` in the linux kernel revealed that XDrawText can return
a BadLength error, which is not mentioned in the man page.
Glancing at the xorg-server source for doPolyText() this is found:
1192 else { /* print a string */
1193
1194 unsigned char *pNextElt;
1195
1196 pNextElt = c->pElt + TextEltHeader + (*c->pElt) * itemSize;
1197 if (pNextElt > c->endReq) {
1198 err = BadLength;
1199 goto bail;
1200 }
So there appears to bea fairly arbitrary ceiling on how many items one can
pass to XDrawText, and it probably depends on the cumulative length of the
individual items overflowing the maximum request length.
Well.. that's lame, and shrinking the maximum items makes it less likely to
trip over this in practice, but it probably just takes a long enough
individual item to trigger it again.
I had erred on the side of "excessively long" assuming XDrawText would just
deal and clip the text to the bounds of the destination drawable, just in
case there was an argv with lots of tiny items, then that would be covered.
This approach is incompatible with the potential for BadLength errors, so
drastically shrinking the maximum number of items until further notice.
|
|
This makes no functional difference, but silences warnings about
unused variables when -Wall is enabled.
|
|
|
|
|
|
|
|
vmon introduces a non-overlay usage, monitors is correct but ambiguous,
graphs is also amiguous, charts is short and distinctive.
renaming of the files comes in a separate, future commit.
|
|
|
|
The font one in particular is likely on random systems...
|
|
This is nowhere near done, but it's a step in the right direction.
Making an attempt to clarify the overlays code and reduce the amount
of awful muddy raw Xrender calls scattered all over the place.
|
|
|
|
This doesn't happen frequently and has gone utterly unnoticed as harmless,
but it's something I noticed in reviewing the code for more lingering style
issues.
|
|
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.
|
|
In vwm_xevent_handle_map_request() XMapWindow was always directly being called.
When we have a vwin, we really shouldn't be calling XMapWindow() since
we can't detect the generated MapNotify like we can with vwm_win_map().
|
|
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.
|
