Hello, One of the most requested features from FVWM is the ability to have per-screen pages/desks. Unfortunately, this is a really large change, and given that FVWM has pages as well as desks, compounds the problem.
The EWMH specification doesn't say anything about per-screen desks which is annoying as it's not possible to have a separate root window per-output. Were it possible, then the XAtom hints would make this easier to achieve. As there's currently only one root window, only one XAtom can be set to indicate the actual desktop in use, and this breaks down with more than one screen. But you can emulate this behaviour by using States. This is a FVWM feature whereby a window can be placed in a state and can then be manipulated by FVWM commands. What I've done is to assign ten states per monitor, and to have those states attached to the output(s) which are present. So for example: screen 0 has states 0 -> 9, screen 1 has states 10 -> 19, etc. There is a limit on the number of states (currently 31) so this will run out quite quickly with more than four monitors. But I'm assuming that's quite rare. When FVWM starts, each output is assigned a current state. This state is the one which is the state being shown. Windows, if they don't have a style indicating a state to place them in, are put in the active state. These variables are tracked via the InfoStoreAdd command. The same operation applies when windows are moved between screens. Windows started without being told which state the window applies to are started on the screen with the mouse pointer, and the state which is on display at the time. Hence: Style * InitialMapCommand AssignTag $[infostore.screen-$[w.screen]-ActiveTag] Windows can be told to appear on another tag as in: Style SomeApplication InitialMapCommand AssignTag 13 If the tag in question happens to be on another monitor, then the window is moved there. If the state in question isn't the active one, the window is hidden. Hiding windows makes use of iconifying with the following condition: Style * !Icon FvwmButtons is set up with one instance per monitor, showing each state, and which ones are for which monitors. If a state has a window on it, the title of the buttons is updated to include a little asterisk at the end. Switching to that state shows the windows on it. Additionally, the buttons are colour-coded to show which state is the active one. If a state contains a window which has the urgency flag set on it, the colour of that state (if it's not the active one) will turn red. A sample screenshot illustrating this can be seen here: http://picpaste.com/pics/state-342X4FRT.1464099362.png The configuration for all of this currently resides in a Gist, found here: https://gist.githubusercontent.com/ThomasAdam/7c19827686481383a6ff8a24bbb3bc2c/raw/937529b7384041b053b0ca56d6f3bccbcda7b012/gistfile1.txt Because I'm using Infostore to track the Window IDs and which state they're assigned to, this does all go a little pear-shaped when FVWM is restarted. I'm working on making Infostore persistent across reboots, the code for which is here: https://github.com/fvwmorg/fvwm/commit/df160edfcd59ffb83e899abbed0d777cd33ffdd9.patch But I consider that a rare thing, so not so much a problem for now. Note that this is still rather rough around the edges, and I do plan on cleaning it up. But for now, it's rather functional. Comments and feedback are welcome. -- Thomas Adam
