| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
- 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.
|
|
In preparation for vwm_overlays_* encapsulation of overlay global state
and general cleanup therein.
|
|
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.
|
