COMPOSITE (only relevant when monitoring overlays are enabled): - Sometimes popup dialogs seem to take more than one try to get displayed, observed in GIMP during testing. Right clicking in the image took two tries. - There's often an extra row included after the process heirarchy in the overlays. This depends on wether the client process' monitor was installed first by the automatic following of children in libvmon or the vwm explicit process monitoring of _NET_WM_PID. There's an extra row included depending on how the race played out, and it's probably because count_rows() is employed in xwin_monitor() to initialize xwin->heirarchy_end but it's not making any effort to be proc->is_new aware or something. Since an extra row is relatively harmless I haven't bothered to fix it yet. - There are a number of optimization opportunities left on the table. * The heirarchy (top) portion of the overlay text is redrawn on every maintain_overlay(), even if it has no changes. (text only, not the graphs) *** this has been changed to only happen if compositing is enabled. * The shadow layer is inefficiently created with 4 renders through the text as a stencil at 4 offsets to create a shadow on every compose_overlay() call, even if the text is unchanged since the last compose. - keep a cached version of the text shadow for reuse if the text is unchanged. (depends not just on the heirarchy portion, _all_ the text layer) - find a better way to create the text shadow than 4x renders through the stencil. *** already improved with a shadow layer maintained as the text layer changes. When the heirarchy rendering becomes more change-aware, so will the shadow updates. * Snowflake maintenance is probably copying more area than it needs to when shifting, it's not aware of snowflakes_cnt. * Heirarchy rows are erased unnecessarily in maintain_overlays(), but this is part of excessive heirarchy redraws. * poll() timeout isn't calculated very well, extraneous wakeups and gettimeofday() calls are being performed. - This matters even when compositing is off, since we always maintain monitoring, unless Hz is turned down to 0. * Overlays are essentially triple buffered since they're composed into the xwin->overlay.picture @ compose_overlay(), then paint_all() renders xwin->overlay.picture into root_buffer after rendering xwin->picture into the root_buffer in composing the screen contents, which then gets rendered into root_picture where everything becomes visible. It's possible to instead have compose_overlay render directly to root_buffer after xwin->picture, but it makes things a bit more complicated and will require some refactoring. At least this overhead is only present when compositing is active. - Cleanups. Much of the current compositing code is taken from a prototype branch and merged with the latest vwm2 tree to create vwm3. There are numerous inconsistencies and just crufty things going on, but that will improve with time. - libvmon could easily be monitoring other system things at little additional cost: * battery capacity/charging status/rate * thermals * cpu frequency * diskstats * network interface counters * wireless interface signal strengths it would be helpful to have another overlay visualizing these system-wide things - There's a mildly annoying latency between switching Hz (Mod1-(Left|Right)) and its value changing visibly in the upper right corner of a window overlay. This is mostly only noticable when switching to 1Hz. The cause is that status gets updated by the sampling callback, which is delayed by the sampling interval. When the interval is 1Hz, there's a ~1 second delay. A refactoring should probably be done which allows maintain_overlays() to have a redraw mode where no sampling has taken place and we want to simply reproduce the last state, but we need to redraw everything in response to things like Hz changing or a window reconfiguration. (a similar latency is observed when resizing a window, the overlay doesn't visibly adapt to the new dimensions until the next sample is taken) These are relatively minor issues, fixing them is a matter of polish IMO. - Streaming snowflakes to a png file when some kind of record button has been pressed for the focused window would be interesting. Not to produce an animation of any sort, but more like a scrolled record. XINERAMA: - XRandR events removing screens containing windows turns them into pseudo-phantom windows. You can reclaim them by Mod1-Tabbing to them (which you can infer by not seeing a green square anywhere visible) and using a window autoconfiguration hotkey like Mod1-enter or Mod1-]. *** May require Mod1-Shift-Tabbing now actually. vwm should detect when screens disappear containing such windows and move them to another screen, even if it's just the 0,0 coordinate of a present screen. - Add a modifier for window configuration hotkeys to become pointer-relative, so one can move a window to a different screen while resizing it by simply having the pointer in the desired screen and hitting the appropriately modified resize command. - There's no direct keyboard method for migrating a window to another screen, much like one can migrate windows from one virtual desktop to another by simply holding shift while switching, it should have something similar for moving a window to the next screen within the same virtual desktop. This could also be autoconfig-aware, so if you migrated half-screened window to another screen, the autoconfigure could recur adapting to the new screen's potentially different dimensions... This isn't difficult to implement, just need to come up with a good key for it. Mod1-Shift-Tab is already taken for switching focus across screens. Maybe it makes more sense to assign a new key to switching focus across screens rather than modifying the Tab, then shifting that key will turn it into a screen migration. - If shelf semantics were murky before they're muddy with Xinerama. *** a particularly annoying issue is shelved windows don't get put in the same screen, I'm leaning towards the screen vwm started with the pointer in (the one the logo gets drawn on) gets assigned as the shelf screen too. *** Instead it would probably be more convenient to have the shelf always appear on the currently focused screen at the time of being toggled. This just requires shelf focusing of windows to always configure them on the focused screen (fullscreening already happens at tht time so it should be trivial to move them to the current screen as well) *** in the mean time, the shelf follows the screen containing the pointer. *** maybe Mod1-Shift-Tab in the shelf context should move the shelf to another screen... vwm is supposed to do what is expected at all times, when it doesn't it's a bug (which are numerous). It's kept simple to promote success in achieving this goal, and even so this has proven quite challenging. Xinerama introduces many new interactions which will require time and thought to make behave as expected. I don't know what other WM's are like in this regard, but find multihead vwm pretty annoying in its current state. *** The usability of multihead vwm has improved substantially with the introduction of screen fencing (for Mod1-Tab) and the explicit violation of those fences (Mod1-Shift-Tab). BUGS: - The introduction of re-Mod1 origin restoration has made some inconsistencies much more visible; if you enter the shelf and try re-Mod1 to your origin, nothing happens because shelf entry doesn't grab the keyboard / start a "transaction". It's probably time to revisit the categorizing of which operations are grabbed vs. ungrabbed, because the utility of re-Mod1 is such that unless it always does what you expect it's very unnerving/jarring, because you become dependent on its remembering where you started and when for whatever reason it didn't remember your origin there's a WTF GRR moment, relative to how awesome it is normally. Also the current implementation returns you to the origin *window*, if your operation migrated the window and you try to return to origin, you go nowhere because you brought the window with. In this situation, you probably expected it to return you to your origin *desktop*, and it should probably return you there when the operation was a window migrate, for example. Let's live with the minimal changes for now and see where all the UX rough edges are before going too crazy. - The halfscreen/quarterscreen shortcuts are treated as user-configured windows clobbering the cached original client configuration, I don't think this is the right thing to do. I'm leaning towards all the shortcutted configurations being treated as various forms of fullscreened state which don't get remembered in window reconfiguration, keeping the other configuration available for window restore. But maybe there's a need for more flexibility. Below I talk about keeping a list of window configurations per window in MRU order then have a way to cycle through them... perhaps it makes more sense to just have a last-configuration cache in the window instance, as well as a cache of the most recent non-shortcutted (either original client configuration or one that was manually sized) available with a modifier. Like Mod1-Enter flips between the two most recent configurations, and adding Shift always brings you back to the original size? *** for now Mod1-Enter fullscreens a non-autoconfigured window, or restores an autoconfigured window to the latest non-autoconfigured dimensions. All the half/quarter/full/all screen modes for windows are uniformly considered autoconfigured states now. The functions have been consolidated... - I suspect there are some situations where the MRU desktop is updated but shouldn't be, but I haven't made a significant effort to specifically isolate and characterize them, just something I feel like I've groaned about occasionally when something unexpected occurred requiring a Mod1-Space storm. * MRU-based window migration (Mod1-Shift-Space) updates MRU without a Mod1 release, that's a bug, no commit has been done. - Seems like there's a bug when exiting a shelved transmission without waiting for it to fully exit before returning to a virtual desktop. Upon switching to the virtual desktop the other shelved window had originated from it is shown erroenously with a focused-shelved window border with the other windows of that desktop. - Audit the code for memory leaks, I don't clean up things diligently on destroy of things, especially surrounding X resources I presume. - A floating window in the shelf, even when rendered as focused, doesn't behave as it's focused.... this is really annoying. I really need to formalize the multi-window (new window) behavior within the shelf, it's totally undefined currently, I just avoid launching things in the shelf and don't run apps which create windows from within it. ... Window creation while in the shelf is still a bit odd. The shelf isn't intended to be a multi-window context, but it probably makes sense to allow temporary situations on new windows in the shelf where windows coexist/potentially overlap. In such a situation, the new window should be mapped and raised but not focused, as well as being flagged as shelved. Focusing the newly created window via Mod1+Tab or a click-to-focus should not unmap the currently focused window, but should focus the new window, temporarily adopting virtual-desktop behavior within the shelf. If the window is closed/destroyed, the previously focused shelved window resumes focus. If the shelf is exited and reentered, the newly created and shelved window becomes the exclusively mapped and focused window. The multi-window state within the shelf is a transient one which ceases to occur the moment the shelf context is left or a subsequent Alt+Tab further cycles the focused shelf, unmapping the currently mapped windows. ... Shelf is like the junk drawer, I don't think it matters, as long as I can throw windows I want out of my main workflow there and eventually find them should I need to it's working well enough. It's not really where any time gets spent other than queueing music in cmus or checking on gtk-transmission downloads. It might be interesting to have a concept of a persistent shelf actually, I tend to _always_ launch alsamixer and cmus in the shelf. I'd appreciate that happening automatically on startup. Humm... then it becomes appealing to assign specific identifiers to their respective shelf windows rather than having to skip through the shelved windows searching, slippery slope. Fuck it, let's consider this; Mod1_` continues to toggle the shelf, then Mod1_1-0 focus the 1-10th persistent shelved windows? They all exist in the shelf as before, in MRU order, cyclable via Mod1_Tab, but Mod1_1-0 are shortcuts to the first 10 shelved windows in shelved order? Or is it reserved for specifically persistent shelved windows which have been specified in the code somewhere, like a launchers.def-like list (shelves.def?)? It's actually somewhat complicated to launch an X client into a specific context. I abuse resource classes for identifying the xterm-based console window and placing it in the shelf with the red border. If I wanted to have automatically launched clients @ startup getting placed in the shelf, it's not necessarily safe to assume every client can specify a class for vwm to recognize like xterm -class, not to mention that's a resource class, it has existing semantics and I've just overloaded it for the console. The clients may not want to have their resource class changed arbitrarily... there needs to be a better way. As an interim solution, what I could do is generalize the launching and shelving of commands (like the console) according to their class. I currently only want to put things under xterms into the shelf at startup anyways, so the xterm -class hack fulfills my immediate needs, and I already basically do it for the console so this would just be more of the same with a generalized implementation. Things like -class VWMMixerXTerm and -class VWMCmusXTerm, define them in a shelves.def where their commands and keysym ids are assigned as well, throw the console in there too removing its specialized shit from vwm.c then generate the startup, identification, and shelving code for all those listed in the file. Worth it? All to save having to launch two xterms and running alsamixer and cmus every time I boot my computer more or less? Unsure. It might be nicer to also have them directly locatable via Mod1-1 and Mod1-2, perhaps suppressing the MRU update on direct addressing to not pollute the MRU of the ephemeral shelves. (this bug entry has become a feature monologue) FEATURES: - Introduce a run command key? Include a modifier for focusing the console upon execution? So you can directly launch (without creating an xterm) command lines? Initially I thought it might be a good idea to make vwm interactively take the input for the command in a custom widget of sorts. But after sitting on this for awhile and giving it more thought, I don't think that makes any sense. It's very rare when I know specifically what I want to run with precisely the right arguments from the correct directory without some filesystem navigation, reverse history search, and perhaps an --help invocation or two. For instance, these days I'm often getting on various wireless networks and I invoke wpa_supplicant directly using a locale-named configuration file as root largely via an reverse history search of the locale's name. What I do today is I create an xterm for wpa_supplicant and shelve it, which wastes a page in the shelf list on an xterm I'm really unlikely to need to visit. The reason I'd like the run command is for launching things like wpa_supplicant without dedicating an xterm to it. It would also be nice to run some of these things under screen so they don't necessarily have to exit should I exit vwm/X. Losing wireless connectivity because I quit vwm is annoying sometimes, like if I'm doing alot of restarting vwm experimenting or something. Maybe what makes the most sense is for a run command to simply focus the console in the shelf while sending the console screen session the remote command for creating a window. Or maybe there should be a separate console session for executing run commands like wpa_supplicant/cmus/alsamixer? Just because it would be cumbersome to navigate a polluted screen session full of all the X clients in addition to the interactive launches, when you're really only going to be interested in the interactive launches. In essence, this is a vwm binding for ^a-c in a dedicated per-X-display screen session (would it be useful to make it a global per-user screen session? could multiple vwm instances share a launcher screen? DISPLAY= would be correct for just one of them, but that has no effect on non-X processes. Interesting to consider, but is there any practical reason to have multiple vwm's running for a user? Unless you're hacking and experimenting with a new feature long enough to want to try live in it for a few hours without leaving your current production arrangement? Unsure. - Mod1+enter currently toggles between the currently user-specified (starts out at client-configured) dimensions, and full-screen. I think it would be useful to support 3 states, the client's originally configured dimensions, the user-specified dimensions (if they have been varied from the client-configured dimensions) and full-screen. This needs more thought, because it might not be very intuitive to sometimes have 3 persisted window states vs. 2, depending on if the user has reconfigured the window dimensions, perhaps it should just always be 3 but sometimes 2 of them are identical. *** this is slightly different now, but I still think it might be useful to keep the original client-supplied configuration available, so a tristate may be cool, keeping the bug entry for the time being. - Mod1+right click resizing should insert a short delay before actually applying motion events for resizing, this better facilitates the use case of click-focusing without raising, without accidental resizes occuring. This window of time could also be leveraged to discover on what axis the resize is to occur (compound vs x vs y). The resize outcome of the motion events which occur in this delay period should still become realized rather than discarded, should the resize last long enough to become realized rather than suppressed and treated as only a focus without raise event. - Mod1+tab currently changes the window stacking order by leaving intermediate windows raised, even though they were simply visited. This is common in WM's, but what I really want is for the window focused at the time of Mod1 release to be the only window remaining raised. The intermediates should only be temporarily raised when they were visited but restored to their previous position in the stack at the subsequent tab press. - Window placement is static, at least cascade, preferably intelligent placement resorting to cascade when the desktop is filled. I actually like how wmaker 'auto mode' tries to fill open spaces with window placement then falls back to cascade once no open spaces exist to accomodate the created window's preferred size. *** funny how simply throwing all new windows in the corner is pretty damn acceptable, at least it's deterministic, moving it is easy enough. *** still unsure on this, deterministic placement is pretty nice. - With the introduction of Mod1-[], Mod1-Shift-[] for halfscreens, and the repeaters for quarter windows, most appreciable XGA window layouts are quickly achieved with the keyboard alone. However, on higher resolution screens, quarter windows can still be too large with high probability. I'm thinking it might be better to adapt the current technique to a more generalized quadtree-inspired navigation. By quadtree I mean incremental recursive bisection of a window along choosable axis in simultaneously chosen directions. So Mod1-[ would be left subhalf bisecting the X axis, Mod1-] right subhalf bisecting the X axis. Shifted Mod1-[ would be top subhalf bisecting the Y axis, and shifted Mod1-] the bottom subhalf bisecting the Y axis. The subhalves are always confined to the window's current space, the recursive bisecting continuing until the Mod1 is released. If Mod1 is released, then the bisection resumed, the process will restart from the screen half initially chosen. It might also be interesting to support a means of going "up" the tree rather than down, to enlarge the window on a chosen axis and direction, additionally it may be useful to move the window laterally in its current dimensions along quadtree-aligned boundaries. Or maybe it's simply good enough to restart from a toplevel half when you wish to effectively move up or laterally in the virtual quadtree. - Resistive edges would be handy, at least screen edges, but window edges can be nice too. It's not that much code to add it, and it makes things much more usable for when the autoconfigured window options aren't fitting the situation... - Virtual desktop genesis needs to query the user for the name, and create a full-screen xterm running screen -S $desktopname for the root (or something) (perhaps something like specifying special per-virtual-desktop classes to the xterm creation can be used to establish desktop affinity and apply special rules to these per-desktop screen-under-xterm sessions) The per-desktop fullscreen xterm can be automatically made borderless when it's shown alone, and bordered when overlapping. A key combination can be defined to (un)map all windows on a desktop except the "root" fullscreen desktop window. This may be achievable entirely via resource classes (xterm -class) so vwm can identify these special per-desktop xterms. * I think it might make more sense to just add a concept of virtual desktop "leaders", and have the default be a fullscreen xterm running screen, but also allow it to be anything defined in launchers.def (added labels to those anticipating a possible best-match search to be performed @ genesis). Then vwm can have a key for "show leader" which hides everything on the focused desktop except the leader window. A key can also be added to assign leadership to any window, but the common pattern would be to @ desktop genesis time establish the leader when it's created, and that will usually be a fullscreened xterm running screen with a named session you name interactively immediately after Mod1-v. Of course there would also need to be the opposite of "show leader" which would probably just be the same key pressed again like a toggle, to show the inferiors. I think there's an important subtle detail in the leader/inferiors visibility toggling to make it particularly useful, and that's one of focus. Show leader should focus the leader, but show inferiors should probably restore focus to the inferior if one was focused at the time show leader was performed. Maintenance of the window stacking order would be helpful too in this case, which is something I don't maintain at all right now. - Implement screen lock (right now I use xlock, I want something integrated which does the following: * disable sysrq on screen lock via /proc/sys/kernel/sysrq, restores sysrq on unlock * disable VT switching on screen lock (unsure how right now), restore VT switching on unlock * if possible, disable ctrl-alt-backspace, allowing me to run Xorg with this enabled without making my desktop totally insecure. When unlocked I like this ability, but when locked it can't be available for obvious reasons. *** I think the best way to achieve this is to actually extend the Xorg server to support the window manager sending two new requests: 1. "close all backdoors" 2. "restore all backdoors" Then the window manager can send request #1 prior to running any lock displays, and #2 upon exiting a lock display. *** Queried Keith Packard (fd.o) on this topic, he thinks it makes sense and might be appropriate to add to xinput or xkbd extensions rather than creating a new one.