diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 432 |
1 files changed, 0 insertions, 432 deletions
@@ -1,432 +0,0 @@ -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. |