FvwmButtons on FVWM3

[lgsobalvarro]

If using only one monitor FvwmButtons is never placed, even if it's loaded manually via FvwmConsole. This issue is persistent with the default config and my custom. xsession-errors does not show anything unusual with FvwmButtons.

If using two monitors FvwmButtons is placed in the second screen, but FvwmButtons is not placed where it's supposed to be. Once again, this occurs with the default, and my custom config.

Tested on OpenSUSE Tumbleweed. FVWM was built without Rplay support.

[ThomasAdam]

Hi,

I've heard of this. How is the geometry of FvwmButtons being specified? Can you dig around the configuration?

I suspect it's a relative geometry, in which case I'll have to take the origin output into consideration.

[lgsobalvarro]

This is the only line on my cfg that is related to Geometry.

*FvwmButtons: Geometry -0+0
*FvwmButtons: ButtonGeometry 64x64-0+0

[MasterP-theGu]

I'm testing on a RPI4 using Arch and think I can add info here.
I'm testing with the default config as well as my own version (which is still heavily based on the 'new' default)

Buttons are called with "*RightPanel: Geometry 120x$[vp.height]-0+0"

Same one-physical-screen-issue here, then the buttons are not displayed at all.
Dualhead issue here with a 1920x1080 as a primary and an old 1280x1024 as a secondary screen

When I have two physical screens attached, the buttons are displayed on my primary screen as expected, but not placed on its right margin, but "somewhere in the middle". This "somewhere in the middle", however, would be exactly the right margin of my smaller secondary screen.
And it is exactly the right margin of what my system seems to "think" is where my screen ends. I hope I can explain this in my layman's terms with this: Usual behaviour of one-screen-setup: I start a full-screen application like Midnight Commander on the console and it fits the whole screen. Unusual behaviour with my dualhead setup with a large primary and a small secondary screen: Midnight Commander takes the whole vertical space but only the horizontal space relative to the 100% width of the second screen (where it is mirrored, anyway, and where mc fills the whole screen).
The space to the right of the RightPanel, though, is treated as expected, the x-value simply goes on and beyond the 1920 onto the second screen.

Workaround for now: I've changed "-0+0" into "+0+0" and have my RightPanel fixed to the left margin of my primary screen.

Setup using xrandr, no xorg-conf or xinerama as far as I can tell (which means: at least not consciously switched on).

[MasterP-theGu]

[MasterP-theGu]

[MasterP-theGu]

[MasterP-theGu]

I hope the pictures can show in how far the ta/gh-22 branch miscalculates the hight of the screen.
As you can see from the console picture, the calculation of the width of the screen seems to be identical with the one my machine (raspi 4, Archarm armv7h) uses internally.
Strangely enough, fvwm2 and as far as I can see the current build of the master branch calculate at least the hight correctly, in both cases, the logout window is in the middle of the two screens, and fvwm2 also gets the width correct, while fvwm3 has trouble with width (that's why I moved the panel to the very left).
Different kind of screenshots. :D

[lgsobalvarro]

Yes. That happens when you use two monitors with fvwm3. But I think this issue is actually related to #22, hence why it also affects the logout window. But I may be mistaken.

[ThomasAdam]

Hi,

@lgsobalvarro and @MasterP-theGu -- I've just pushed a new fix for #22, can you test that to see if those changes also fix this problem?

Thanks!

[lgsobalvarro]

Hi @ThomasAdam

No. The problem still persists at least for me. However I did notice a change.

1. I ran fvwm3, using only my main screen. FvwmButtons where nowhere to be seen.
2. Plugged my 2nd screen. and activated it via arandr. FvwmButtoms then was palced correctly on Screen 1.
3. I restarted fvwm3 so the wallpaper could fit correctly screen 2, and FvwmButtons where place incorrectly in a similar fashion as shared by @MasterP-theGu

[MasterP-theGu]

Sorry, I only came to my study now. Built the new #22 and ran it with a clean config.
The vertical issue is gone, screen hight is correctly calculated, Time and Date are visible, the quit-dialogue appears in the middle of the cumulative screen estate of my two screens.
The RightButtons, however, are still placed in the same wrong place as in my screenshots.
Before I unplug the second screen, I realised something in the RightPanel:

FvwmIdent returns the actual placement of the panel. In my modified config, I start the panel with
*RightPanel: Geometry 120x$[vp.height]+0+0
and FvwmIdent returns
Geometry 120x1080+0+0

When I start the new build of #22 with its default config, the config (which misplaces the Buttons) says:
*RightPanel: Geometry 120x$[vp.height]-0+0
FvwmIdent in this case returns correctly
Geometry 120x1080-1920+0

(I tried to figure out the vertical equivalent of vp.height, but to no avail, so I can't test that.)

[ThomasAdam]

So... FvwmButtons in this case will start up on whichever screen has the mouse pointer, since that's how the calculation is performed.

Either way, I'm still finding FvwmButtons being placed on either right edge of the screen, and not in the middle of the screen, per your screenshots.

[lgsobalvarro]

I think the issue is related to the fact that both screens have different resolutions. In my case:
Screen1: 1366x768
Screen2: 1920x1080

Posisbly fvwm/randr or whatever is assuming both screens have the same resolution (1920x1080) so, that's why FvwmButtons is misplaced.

Update:
After setting both screens to 1280x720 and restarting fvwm3, FvwmButtons is place correctly.
If the resolutions are different buttons is place incorrectly, it doesn't matter if screen1 or screen2 is set as default, the end result will be the same.

[MasterP-theGu]

I know it's silly to just repeat what someone else has already said or written, but it might make sense to confirm Igsobalvarro's obvervation. No matter which one is the primary screen, xrandr (like the console) takes the smallest / most narrow resolution to define where "+0+0" is.

UPDATE:
A workaround that might (or might not) hint at a possible scripting solution to how fvwm3 can correctly determine "+0+0" only on the primary screen is a chain of commands involving autorandr (https://github.com/phillipberndt/autorandr):

Once

1. create config autorandr for the correct resolutions (say, autorandr --save real2)
2. create config autorandr for two screens of identic resolution (say, 'autorandr --save fake2')
   then "always"
3. start fvwm3, run 'autorandr fake2', restart fvwm3, run 'autorandr real2'.

[ThomasAdam]

Hi all,

Please can those of you who were running in to this problem compile FVWM3 from the ta/gh-28 (HEAD commit is ae60eca) branch and tell me if this fixes the problem you were having?

How, with the specified FvwmButtons geometry, the panel is always placed on the furthest right monitor configured.

Thanks!
Thomas

[NsCDE]

The ta/gh-28 works for me.

My FvwmButtons Front Panel on restart ends up on the bottom center where it belongs. This was not the case past days, while we were testing other things.

[ThomasAdam]

All,

I've closed this for now, as it appears to be working well for me. But please do reopen this issue if it's still not fixed.

Note that in fvwm2 with Xinerama, the position of the FvwmButtons would be relative to the designated primary screen. FVWM3 doesn't have such a concept, and hence $[vp.width] and $[vp.height] are therefore the values returned across ALL monitors. So for example, if you have three monitors configured via RandR in a row, then FvwmButtons will now display on the third monitor.

[lgsobalvarro]

Hi @ThomasAdam

Sadly is not working quite well for me.

FvwmButtons is being placed in the secondary screen (1920x1080), not in the primary (1366x768). In addition FvwmButtons placement responds to the primary screen, not the secondary. A similar issue occurs if I set the secondary as primary.

Maybe I'm missing something on my configuration, that tells Fvwm to place Buttons on the primary screen. It may be user error.

If there is any other additional information that could be fo help to you, pelase let me know.

[ThomasAdam]

Hi @ThomasAdam

Sadly is not working quite well for me.

FvwmButtons is being placed in the secondary screen (1920x1080), not in the primary (1366x768). In addition FvwmButtons placement responds to the primary screen, not the secondary. A similar issue occurs if I set the secondary as primary.

That's because in FVWM3 I haven't written any logic to use the primary screen (even though FVWM3 does track which is which).

Maybe I'm missing something on my configuration, that tells Fvwm to place Buttons on the primary screen. It may be user error.

It's not a user error, no. Just an omission. I'll fix this.

If there is any other additional information that could be fo help to you, pelase let me know.

Other than not using the primary screen, I presume the placement is now consistent across monitors (i.e., isn't in the middle or off to one side, as in @MasterP-theGu's screenshots?)

Thanks,
Thomas

[lgsobalvarro]

It is, well... kind of... If I set both screens to use the same resolution (1280x720) it works perfectly, and is placed on my primary screen in the correct place.
But after using kruler to track down the exact position when I use the "optimal" resolutions... I realize most likely is due that you just said: FVWM3 does not know "know" witch screen is set as primary. So it's calculating for screen1 but placing on screen2

[ThomasAdam]

Hello again everyone,

Thanks, @lgsobalvarro. I don't think there should be an issue with different sized monitors as that's what I'm using for testing.

I've pushed 9707b2b to ta/gh-28 -- this time, the primary screen is taken from whatever has been set via xrandr.

[lgsobalvarro]

That did the trick.

FvwmButtons is now being place correctly on my 2nd monitor.

[ThomasAdam]

OK. Cool. Would you say this is now in a mergeable state?

[lgsobalvarro]

Seems so. I'll play with it more next week. Let's see to if it works well enough for @MasterP-theGu too.

[MasterP-theGu]

Yes, it works fine on this side of the channel, too.

[MasterP-theGu]

The RightPanel is placed on the rightmost edge of my primary screen, and with my config (*RightPanel: Geometry 120x$[vp.height]+0+0) it stays on the leftmost edge of my primary screen after reboot, even if I reboot from secondary screen; before the most recent changes, a restart from the second screen had moved the panel to the left of the second screen, so that's definitely a thumbs-up.

[ThomasAdam]

Thanks everyone. Will merge to master.