summaryrefslogtreecommitdiff
path: root/src/Makefile.am
AgeCommit message (Collapse)Author
2021-01-02context_colors: introduce context colors list X-MacroVito Caputo
preparatory commit for generalized contexts replacing the shelf
2020-12-23direction: introduce vwm_direction_t enum typeVito Caputo
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.
2017-03-25overlays: rename overlays.[ch]->charts.[ch]Vito Caputo
2017-03-21vmon: introduce vmon utilityVito Caputo
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.
2017-03-14overlay: rename overlay.[ch] -> overlays.[ch]Vito Caputo
In preparation for vwm_overlays_* encapsulation of overlay global state and general cleanup therein.
2017-03-14xserver: introduce isolated core xserver apiVito Caputo
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.
2017-03-14vwm: split out helper macros into util.hVito Caputo
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.
2016-09-09build: Adopt GNU automake (and thus autotools)Vito Caputo
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.
© All Rights Reserved