Re: FVWM: Per-monitor tags/groups

[elliot s]

>> It looks like your code is doing ChangeButton colorsets also.
>> Is that a post 2.6.6 change?
>
> Yes, on the master branch, will be in 2.6.7. No release date set for that,
> but master should be stable, so I urge you to try it.

Since i wasnt running xinerama, i only had one "screen". So instead i
edited the c code to get the pagers/taskbars to look at only the
windows on their half of the page, by checking against window's x.  It
would be nice if instead modules could be told which states to skip.
Then each window could dynamically control who uses it by setting
State.

Re: FVWM: Per-monitor tags/groups

[Thomas Adam]

On 24 May 2016 6:53 p.m., "elliot s"  wrote:
>
> I did dual-monitor by creating a backing desk per second monitor page.
> Monitor 2 paging was done by moving windows between backing and current
desks.
> I also used temp sticky for monitor 2 windows during monitor 1 paging.

See the 'ta/fvwmdx' branch in git for a module which does this  but breaks
the FvwmPager.

Thomas Adam

[fvwmorg/fvwm] f42e92: TODO: Fix formatting

[GitHub]

  Branch: refs/heads/ta/todo
  Home:   https://github.com/fvwmorg/fvwm
  Commit: f42e92ac25bf249c70cbb91493bada301c32ce6e
  
https://github.com/fvwmorg/fvwm/commit/f42e92ac25bf249c70cbb91493bada301c32ce6e
  Author: Thomas Adam 
  Date:   2016-05-24 (Tue, 24 May 2016)

  Changed paths:
M TODO.md

  Log Message:
  ---
  TODO: Fix formatting

FVWM: Per-monitor tags/groups

[Thomas Adam]

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