On Sat, Dec 04, 2021 at 11:14:09AM +0000, Hegel3DReloaded wrote:
> On Saturday, December 4th, 2021 at 11:39 AM, Dominik Vogt
> <dominik.v...@gmx.de> wrote:
>
> > Okay, that is a real problem. The pager definitely needs to react
> > to changes of the desktop layout, be it by attaching or detaching
> > monitors at run time or by issuing the desktopsize command.
> >
> > The pager should fix that situation itself and not expect the fvwm
> > core to do it. There are two cases and multiple possible ways to deal
> > with it:
> >
> > 1) Pager is using a user specified geometry:
> >
> > a) Stick with the user specified size.
> > b) Resize the window proportionally.
> >
> > 2) Pager is using the calculated default size:
> >
> > a) Recalculate total size and use that.
> > b) Resize the window proportionally but try to keep it close
> > to the current one; at least don't make it much bigger or
> > smaller.
> >
> > The module interface provides the information necessary to
> > implement that.
> >
> > Would 1a + 2b be sensible default behaviour?
>
> By "calculated default size" do you mean DeskTopScale FvwmPager config
> paremater?
I mean the size it would use when started as a standalone window
without any explicit geometry configuration present.
> If yes, then I think yes, 1a if user said so with Geometry parameter,
> no matter what we think of this.
> 2b is a bit of gray area. I can
> imagine some border cases where huge change of resolution or attaching
> notebook to the 3 monitors in a row docking station in mode where
> FvwmPager doesn't have "Monitor" config directive can give odd results.
Yes, it probably needs some configuration by the user.
> If 2b will have logic or more precisely heuristics similar to this:
>
> "if I need to grow more than twice my current size in X or Y direction,
> apply some divisor to make it a bit less space hungry (the result to be
> 1.5 instead of 2 for example), if size is more than 4 times, apply even
> bigger divisor, and the last safety which should never be hit unless you
> emit your screen on some open space expensive concert screen wall with
> insane resolution, stop growing if the resulting pager will be bigger
> then XY in proportion to $[vp.width] and/or $[vp.height]".
Hmmm.
Rules of thumb if no config is present:
* If you switch the desktop layout between two geometries A and B
multiple times, the result should alays be the same.
* If you initially start the pager P1 with desktop geometery A
then switch to geometry B and start another pager P2, both
pagers should have the same dimensions.
I guess it's only possible to stick to both rules at the same time
if the pager geometry is completely recalculated when the desktop
geometry changes?
Maybe the scaling argument can be set to "auto" or something to
keep the desktopscale within reasonable limits? (The example with
desktopsize 50x1 earlkier in the discussion showed that the pager
currently does not have a reasonable scaling algorithm).
> This can be tested in KVM/qemu xrandr changing sharply from 1024x768 to
> 2560x1440 for example, and with configuring RandR to have 3-4 Virtual
> monitors in one row.
Changing the desktopsize at run time also works.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
