path: root/TODO

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.