| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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.
|
|
|
|
We can assume (vwm->focused_desktop != NULL), the initial desktop
is created early in startup and the last one can't be destroyed.
|
|
It's far too obnoxious to use without this enabled.
Some spurious cleanups in the surrounding code landed here as well.
|
|
No functional changes here.
|
|
|
|
I had assumed pread wouldn't work on /proc files and that lseek to the
start was the only safe form of seeking, but this seems to be working
acceptably well even with buffer sizes of 2 requiring many sequential
reads per sample.
The lseek syscalls aren't free and it's nice to omit them entirely,
and we're essentially being sequential in our pread() use, and always
use a buffer that is large enough to fit everything in the first read
anyways.
|
|
The vmon->buf[_bis] buffers are nice to shrink to absurdly small
sizes for testing changes, but we can't do that when they're reused
for path construction.
Just use local on-stack buffers for constructing paths, and now things
continue to function just slower with vmon->buf[8].
|
|
This trivial change eliminates the final EOF realization read() syscall on
every /proc file consumed for every process on every sample, which adds up.
|
|
I think I've developed a force of habit typing `static inline` after
the ray tracer in rototiller.
|
|
Bring libvmon code inline with the direction vwm has headed in terms
of coding style. Entirely mechanical changes with one exception
replacing a free()/=NULL idiom with try_free().
|
|
vmon exposes the monitoring overlays of vwm through a standalone
commandline utility by creating dedicated window for presenting the
overlay.
At this time a single preexisting PID may be specified, forming the root of
a recursively monitored heirarchy. Alternatively, a command may specified
which vmon will then fork and execute on your behalf, automatically
monitoring the child and its descendants for you, in a style similar to
strace.
Examples:
Monitor a linux kernel build in fullscreen mode, note the --:
`vmon --fullscreen -- make -C /usr/src/linux -j8`
Monitor the entire system:
`vmon --fullscreen --pid 1`
For convenience, omitting --pid and a command to run assumes PID 1:
`vmon --fullscreen` is analogous to `vmon --fullscreen --pid 1`
Monitor a linux kernel build fullscreen at 50Hz:
`vmon --fullscreen --hertz 50 -- make -C /usr/src/linux -j8`
Do the same thing but don't exit when the make completes:
`vmon --linger --fullscreen --hertz 50 -- make -C /usr/src/linux -j8`
Help is provided via `vmon --help`, where you'll find all flags described
with their short and long forms.
Some important TODO items include:
- Support for specifying multiple top-level processes
- Support for mixing --pid and running a command
(useful for watching specific system processes while you're running
something specific)
- Support for scrolling within the window. The overlays in general need
to evolve a bit to better support the vmon use case. In vwm there
wasn't any intention of accomodating the entire space if it exceeded
what was naturally available in the existing window's dimensions.
That makes sense for vwm, but vmon not so much.
You can achieve the same thing more or less by resizing the window to be
larger than the screen (easy to do in vwm using a combination of
Mod1-Right-Click to resize, then Mod1-Left-Click to drag the window,
repeatedly. Then just Mod1-Left-Click to grab the window and "scroll"
it by moving the desired part on-screen, repeatedly. Cumbersome, but
works fine in a pinch. Not all window managers can do this though...
Of course it would be less costly to only render what's visible, like a
scrollable window would achieve. This is probably the top priority
TODO.
- Support for monitoring of memory use, files, per-process IO activity.
libvmon supports substantially more than is being visualized currently.
- Support for changing the font.
|
|
In vwm it was only necessary to relatively increase/decrease the sample
rate.
With vmon being primarily a cli tool, explicit setting of the rate is
desirable. This commit reworks things a little de-specializing the zero
value of overlays->sampling_interval, while switching this to instead of
being an index into the intervals table simply contain the float interval
itself. The math.h INFINITY macro becomes the new paused/zero value, and
simply gets an entry of its own in the intervals table as the lowest one.
|
|
In vwm we were always doing a transparent overlay to preserve underlying
window visibility. With vmon this is undesirable and we just want to
copy the currently cached composited contents to the window, which is
also substantially less costly to perform.
Parameterize the operation so vwm and vmon can specify what's appropriate.
|
|
I'm no longer fond of combining one-line conditional statements on
the same line as their conditional expression.
|
|
- Move vmon_proc_t under vwm_overlay_t.
- Privatize vwm_overlay_t.
- Update xwindow.c to dynamically create and destroy overlays.
- Cease supplying vwm_t to vwm_overlays_create(), now just
pass in the bare vwm_xserver_t.
- Update all vwm_overlay_* functions to operate on vwm_overlays_t and
vwm_overlay_t. Only vwm_overlays_create() receives the xserver,
which it then embeds within the returned vwm_overlay_t.
- Eliminate _xwin_ flavors of overlay functions, largely mechanical
rename eliminating the _xwin_ from the names during the previous
pass of switching from vwm_t & vwm_xwindow_t to vwm_overlays_t &
vwm_overlay_t parameters.
- Change vwm_overlay_compose() to store damage in supplied pointer,
the caller is expected to make use of the damage information now
because the overlay code doesn't know about the window its coordinate
space.
|
|
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.
|
|
|
