Hi

I will like to share some of my thoughts about monitor addressing. Maybe you find something useful from this.

In fvwm2, this was a number, monitor number, while on fvwm3, we see RandR provided name in the place of it.

I think there should be two kinds of variables: one with numbers, and one with names. Analogy for this should be gethostbyaddr and gethostbyname - getmonitorybyaddr and getmonitorbyname. :)

Here is why:

Many people have two or more monitors at home and at work place. This monitors can have different cabling technologies and can be called DP, HDMI, DVI, VGA, Virtual, FOO, Bar ... One guy in my department has 3 monitors at work and 2 at home ...

If monitors are referred with their RandR names in the configuration, things will break if one has HDMI1 --right-of eDP1 at one place, and DP2 --right-of eDP1 on other while moving with laptop. Also, connecting projector on presentations/educations can have some funny effects.

Additionaly, there can be the same names (HDMI1 for example) on both places, but in different resolution.

There should be the way to address monitors in 3 ways:

1. 0 as primary and then dinamically 1, 2, 3 as fvwm2 $[pointer.screen] in order they are connected
2. Direction from primary (left, right, above, below) + offset if it is not a nearest one
3. RandR name (as present pointer.screen in fvwm3)
4. Unique (or semi-unique) identifier which can be obtained from EDID, which is as far as I know available to RandR. For example with some helper command to generate some unique string (like iSCSI IQN, or disk WWN) which can be referenced as exact object from configuration

Actually, this are the 4 ways ... But I didn't expected the Spanish Inquisition. :-)

Maybe pointer.screen should revert to fvwm2 numbering and whole new scheme of monitor macros to be introduced. For example, this days $[monitor.primary] was introduced. I think this should continue in that direction with $[monitor.]. Of course, it should be decided for consistency if "screen" should be used for naming or "monitor" (in addition to pages and desks).

I will try to construct an example here:

eDP1 as laptop screen + DP1 as external monitor:

• $[pointer.screen] = 0 for eDP1, then 1 for DP1
• $[monitor.name] = eDP1 and then DP1
• $[monitor.identifier] = scr.54598789447-1 and then scr.76342832982-1 (example)
• $[monitor.$[pointer.screen].position] = (L1 | R1 | A1 | B1 | L2 | R2 | ...) where L/R/A/B are left, right, above, below, and 1, 2 is the offset from $[monitor.primary].
• $[monitor.$[monitor.identifier].position] = same as for $[pointer.screen], but with exact monitors
• $[monitor.$[monitor.name].position] = same positioning for RandR names possibly

From this scheme, I can see some of this benefits:

• xrandr command can be combined with macros and called with Exec/PipeRead from configuration in most if not all possible ways for user to make desirable configuration, wheater some behaviour is wanted for any monitor which is "--left-of" or just particular one by identifier or cabling technology (last one as some workaround possibly like xgamma or ...)

• in combination with proposed events from FvwmEvent from Proposal: FvwmEvent new events in FVWM3 #26, automatization possibilities are even more in the hands of the user

• backward compatible $[pointer.screen] and new consistent naming for new $[screen.X] or $[monitor.X] macros. Maybe "screen" should be used, to be consistent with MoveToScreen, StartsOnScreen and other commands which are already using that term.

Just my 2 ... 3 cents ...