diff options
Diffstat (limited to 'TODO-vwm.txt')
| -rw-r--r-- | TODO-vwm.txt | 432 |
1 files changed, 432 insertions, 0 deletions
diff --git a/TODO-vwm.txt b/TODO-vwm.txt new file mode 100644 index 0000000..7328492 --- /dev/null +++ b/TODO-vwm.txt @@ -0,0 +1,432 @@ +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 hierarchy 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->hierarchy_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 hierarchy (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 hierarchy 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 hierarchy 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 hierarchy 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. |