| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
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).
|
|
|
|
This moves the console teardown back to vwm.c, trivial cleanup.
|
|
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.
|
|
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.
|
