FvwmIconMan doesn't support a RandR screen specification in ManagerGeometry
Closed this issue · 7 comments
Upfront Information
Please provide the following information by running the command and providing
the output.
-
Fvwm3 version (run:
fvwm3 --version)
fvwm3 1.0.7 (1.0.6a-1-g8670b593)
with support for: ReadLine, XPM, PNG, SVG, Shape, XShm, SM, Bidi text,
XRandR, XRender, XCursor, XFT, NLS
xrandr: primary 3840x2160+0+0, secondary 3840x2160+3840+0 -
Linux distribution or BSD name/version
Fedora 37 -
Platform (run:
uname -sp)
Linux x86_64
Expected Behaviour
I have a dual screen HiDPI RandR setup, and I would like my FvwmIconMan window to be in the top left corner of my second (right) screen. In fvwm2 this was easily done with 'ManagerGeometry 10x0+0+0@1', but fvwm3 doesn't support that syntax any more. In theory the documentation suggests you can do this with +0+0@DisplayPort-0 (where DP-0 is my second screen), but in practice the screen specification is ignored and I get the FvwmIconMan window at +0+0 global coordinates (at the top left of my first screen). Looking at the source code I believe this is happening because modules/FvwmIconMan/x.c's X_init_manager() calls FScreenParseGeometryWithScreen() with a NULL final argument, which implicitly throws away the information about what screen has been specified if one was.
Changing the code to call FScreenParseGeometry() instead would probably be a backward incompatible change because, as with FvwmPager in #810, this would make the window position for currently working arguments (ones without a screen specifier) depend on the 'current screen' at the time the module was started or restarted, instead of being global.
Hi @siebenmann
Well, I don't think it would be an incompatible change.
Right now, if you want to use the global screen for geometry references, you have to use ...@g -- the whole point of using ...@ in geometry strings is to specify a specific monitor, so the logic is backwards.
If we changed the logic, it would work as expected.
Pragmatically, right now a ManagerGeometry of '10x0+3840+0' places my FvwmIconMan on the top left of my second screen. If I'm understanding FScreenParseGeometry() default behavior correctly, changing FvwmIconMan to use it would make this geometry only work if my mouse was on the first (left) screen when FvwmIconMan was restarted; if it was on the right screen, FIM would be off-screen to the right. This is because without a '@' in the geometry, FScreenParseGeometry() interprets it as relative to the current screen (where current is defined by the mouse pointer).
More broadly I think that the current situation with geometry is confusing. Ordinary X programs and fvwm code (module or otherwise) using FScreenParseGeometry() interpret the same geometry string quite differently; X programs interpret it as a global geometry, while fvwm code interprets it as relative to the current screen. If there's going to be a change that makes some current geometry specifications in fvwm not work as they used to, I would prefer to synchronize fvwm's notion of what a non-screen-qualified geometry means with what other X programs will do. Ie, make FScreenParseGeometry() interpret unqualified geometries as global ones.
(You may be proposing exactly this change here in your message, in which case I wholeheartedly support it. Pragmatically I think making FScreenParseGeometry default to global probably wouldn't break anyone's RandR configuration, because right now to get things to work reliably you pretty much have to be qualifying your geometries with a screen, even if it's @g for the global one.)
(You may be proposing exactly this change here in your message, in which case I wholeheartedly support it. Pragmatically I think making FScreenParseGeometry default to global probably wouldn't break anyone's RandR configuration, because right now to get things to work reliably you pretty much have to be qualifying your geometries with a screen, even if it's
@gfor the global one.)
Yes -- I'm going to be changing to this for geometry strings without @... in them to be relative to the global screen. This is what you're also suggesting, but you seem to be talking about this in terms of what the code is doing.
Yes, I was thinking of minimal changes. Then after the chance to FScreenParseGeometry(), I think the simple fix for FwmIconMan is to change from FScreenParseGeometryWithScreen() to FScreenParseGeometry(). I just took a look through the code and it appears that FvwmIconMan is the only place that's calling FScreenParseGeometryWithScreen() with a NULL final argument (and not many places directly call it at all).
Have a look at the gh-813 branch. I've not tested this on my multi-monitor setup as I can't be bothered to move from where the open fire is, to my office. But I think the logic is correct...
The code also looks good to me but I won't be able to test it myself for a while, as my only multi-monitor setup is at the office.
I've taken a look at this in more detail, and as a result of the change of logic, I've fixed a further issue in FvwmIconMan's handling of geometry strings for ManagerGeometry.
I'm happy with this change now, so will merge.