| Age | Commit message (Collapse) | Author |
|---|
|
Eliminate some initialization cruft.
|
|
|
|
|
|
Introduce vwm_overlays_t and create/destroy functions, use in vwm_startup()
and vwm_shutdown(). Supply to methods operating on the global overlays
state vwm_overlays_update(), vwm_overlays_rate_increase(),
vwm_overlays_rate_decrease().
This is a fairly minimal adoption of these changes with vwm_t still being
supplyed to the overlay functions.
A future commit will further cleanup the interactions and cease all
knowledge of vwm_t in overlays.c, but for now everything overlay-oriented
still accesses the overlays_t instance via vwm_t. Instead of supplying the
vwm_t to vwm_overlays_create() the bare vwm_xserver_t will be supplied, as
this is the future shared component across vmon and vwm (in addition to
overlays).
|
|
In preparation for vwm_overlays_* encapsulation of overlay global state
and general cleanup therein.
|
|
We need to eventually plumb an vwm_overlays_t reference back to sample_cb,
for now we'll just obviate the need for the vwm_ptr global by plumbing the
vwm_t through.
|
|
|
|
In preparation for monitoring overlays being shared across vwm and vmon,
adding a common xserver abstraction for both to use and overlay to depend
on.
|
|
|
|
In preparation for separating out the monitoring overlay code
from being vwm-coupled, moving these into an independent header
since they'll be used throughout.
|
|
If walking ancestors never entered the loop, bar_y isn't set.
Set the bar_y once per row, and independent of ancestors. This
is obviously more correct and fixes a situation where the siblings
have children but there are no ancestors (siblings under the root).
Surprisingly this isn't generally observed in vwm, but was noticed
in vmon development.
|
|
Tidy up vwm exit handling and stop leaking an X Region on every clean vwm_composite_paint_all().
If you noticed very long-running vwm instances hogging memory like a web browser, this is the culprit, vwm doesn't typically need much memory.
|
|
When vwm_composite_paint_all() short-circuited, occluded wasn't destroyed.
Defer the occluded region create to its time of need, which is after the
short-circuit, and followed immediately by its destruction.
|
|
This moves the console teardown back to vwm.c, trivial cleanup.
|
|
it's not being used for anything as of now.
|
|
|
|
|
|
readdir_r() has been deprecated in glibc
|
|
|
|
Sometimes `mplayer -fs` would result in an unmanaged window. It seems to be
due to an unexpected ordering of events on the window:
create notify 0x1000001
creating 0x1000001
map request 0x1000001
managing 0x1000001
configure request 0x1000001
unmap notify 0x1000001 from configure 0
unmanaging 0x1000001
configure notify 0x1000001
map notify 0x1000001 <----- this happens after the window has been unmanaged!
configure notify 0x1000001
configure request 0x1000001
configure request 0x1000001
configure request 0x1000001
configure request 0x1000001
configure notify 0x1000001
So in handling MapNotify, if the window is !managed && !override_redirect,
manage it.
This is confirmed to fix the occasionally unmanaged `mplayer -fs` window.
|
|
This was a known bug, there's a TODO sitting right there noting it.
The items array was sized very large so it never triggered and was
forgotten about.
Running `make tags` in the linux kernel source steps on it though,
because it constructs a massive argv.
This just adds a bounds check so no crash occurs in argv2xtext().
I don't see the point of allocating memory for this as the TODO's
suggested, since any such argv is unlikely to fit in the overlay
anyways.
Also shrunk the max from 1024 to 512, which is still quite large.
|
|
key: decrement key_is_grabbed release of multi-Alt
|
|
Upon releasing all keys concluding a grab the counter gets reset so this isn't
generally observed as being a problem.
Sometimes the second Alt is released by itself, restoring the origin, and the
original grabbing single Alt persists for subsequent window management
operations. It's in this situation when the bug manifests. If the final Alt
release occurred with a focused window/desktop differing from the origin, on
the final Alt release an unexpected restore to the origin occurred.
Usually this goes unnoticed, because typically the lone Alt release occurs
immediately following the other one, and the second restore to origin happens
to be idempotent.
|
|
House cleaning
|
|
If vmon hasn't seen any heirarchical changes, and we aren't forcing a redraw,
and the process information being shown isn't changed, don't bother
re-rendering the same thing the overlay already contains.
This can be further improved, like if only wchan changed and nothing else, only
redraw the wchan column for the relevant row. It gets tricky quickly though,
because a new wchan could be wider than the column currently permits for
example, then we'd need to go render all the rows to the new wchan column
width...
It's simpler to just redraw it all if anything has changed, and this stuff
doesn't generally change that frequently in practice so it's pretty effective
as-is.
|
|
The samplers may set these, but we need to clear them on every vmon_sample().
|
|
|
|
Set on window resize, clear on draw_overlay() return.
Used in combination with sample_interval check to gate HZ redraw.
Will be used to gate redraw of process monitors heirarchy as well,
in a subsequent commit.
|
|
Also moved vertical graph bars drawing to helper function
|
|
We currently only use the width, and XTextExtents does substantially more crap
per character in Xorg's xlib. XTextWidth is not just a wrapper around it, it's
a specialized subset implementation.
|
|
Trying this out now that there's a pile of files... sigh.
Note this spuriously duplicates list.h @ src/libvmon/list.h, the old Makefile
shared list.h between vwm and libvmon, but I'm letting them have their own
instances with autotools. Libvmon was always an independent project I just
pulled in for vwm's use, and will likely continue to be developed independent
of vwm with occasional syncs.
|
|
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.
|
|
I've warmed up to space after control flow keywords
|
|
Approximately:
s/if(/if (/g
s/switch(/switch (/g
s/do(/do (/g
s/while(/while (/g
s/for(/for (/g
Macro use continues to be spaceless, even when used as control flow primitives
(i.e. list_for_each()), as do function calls.
|
|
Fix handling of non-visible focus switches
|
|
It's inappropriate to assume the window being focused is in the visible
context. This caused the input focus to spuriously vanish if a window on
another desktop went away causing the next one, also invisible, to get focused.
I'm surprised how long I went without ever noticing this bug! My workflow
basically never has windows vanishing that aren't in the focused context.
|
|
This can just be derived from the state of the basis window, I think originally
I had intended to implement context switching via this function.
Also changes the implementation to stop comparing against
focused_(shelf,desktop) which prevented doing transitions on invisible
contexts. It's not usually an issue, but windows can go away at any time, and
we must be able to focus next when they do, even if their context isn't the
visible one.
|
|
Renaming to better describe what this actually checks.
Initially I was leaning towards adding a data structure for actual visibility
checks rather than just assuming all vwm-mapped windows are visible. But
there's a need for knowing just if windows are currently mapped as well, so
this function can stay implemented this way with the appropriate name.
|
|
I didn't experience any bug in particular which brought this to my attention,
but it's an obvious omission, though apparently quite ignorable.
|
|
|
|
|
|
|
|
|
|
See changes to README, but basically if you're holding down Alt and doing
some window management operations, while still pressing Alt hit the other
Alt key to return focus to the starting window+desktop. Nothing is undone,
focus is simply returned to the starting window+desktop.
|
|
|
|
Automatically "autoconf" screen-sized new windows as "allscreened"
|
|
This enables automagic mplayer -fs borderless fullscreened playback windows
with minor additions to the code. Previously one had to focus the playback
window and mod1-triple-k it to lose the borders, now it "just works".
|
|
|
|
Using bash was a bit heavy-handed when all I really want is a /bin/sh -c
just like popen()/system(). On some systems this won't make any
difference, but on Debian /bin/sh -> dash.
|
|
Major changes from vwm2 include:
- Introduction of integrated X client process and descendants
monitoring in the form of per-window composited overlays.
The rendering is done using the Composite, Damage, and Render
extensions. When the monitors are visible, vwm3 is a compositing
manager. When invisible, vwm3 continues to be an immediate-mode
classic X11 minimalist window manager.
Monitors are toggled via Mod1-;, Mod1-LeftArrow and Mod1-RightArrow
may be used to decrease and increase the sampling frequency,
respectively. Mod1-' clears the monitored tasks history for the
focused window when monitoring is visible.
This feature depends on the CONFIG_CHECKPOINT_RESTORE kernel
configuration option for the discovery of descendant processes.
Without this kernel option enabled, you'll only get a single process
monitored per window; the X client process as indicated by the
_NET_WM_PID atom of the window.
A library called libvmon has been introduced for the abstraction of
lightweight system and process statistics sampling.
Since vwm2 received backported features unrelated to monitoring or
compositing while vwm3 was developed, there isn't really much
difference between the two outside the monitoring context.
This isn't to say there isn't much activity in the code, the addition
of compositing and monitoring requires a substantial amount of code
relative to the scale of vwm[12].
|
