Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Monday, December 13th, 2021 at 12:17 PM, Dominik Vogt wrote: > On Mon, Dec 13, 2021 at 07:40:06AM +, Hegel3DReloaded wrote: > > > Yes, I fixed a leak at the cost of introducing a crash. > > > > I see. It is working now. May I close > > https://github.com/fvwmorg/fvwm3/issues/647 > > Ye, please. Closed. > > or you will do it with some description FTR? > Only if forced to. I'm not good with web tools. :-) Me niether, but to be honest, Github web is very responsive and without too much distractions if compared with some corporate shit I need to watch occasionally or equally bad so called "social networks". Thomas made really advanced automation system there. I will try to stick with this as much as I can; I have a feeling it can be fruitful and useful as project mgmt. -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Mon, Dec 13, 2021 at 08:06:41AM +, Hegel3DReloaded wrote: > It appears that on "Restart" Front Panel ends up in the +0 +0, upper left > corner of the screen. It starts ok, it is placed at the bottom center > part, but something relocates it in the last moment. I remember we had this > problem often introduced and then fixed again. > > Now it seems that > > "All (FrontPanel,CirculateHit) PlaceAgain" is causing the problem. That is, > it behaves differently that on fvwm3 1.0.4 and fvwm 2.6.9. It looks like > PlaceAgain is ignoring Style for panel: > > PositionPlacement $[infostore.frontpanel.pos.placement] > > ... where infostore.frontpanel.pos.placement is "screen c 50-50w -0p ewmhiwa" Oh, I had noticed that but thought it was something to fix in the move_loop rewrite. It's fixed now. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Mon, Dec 13, 2021 at 07:40:06AM +, Hegel3DReloaded wrote: > On Monday, December 13th, 2021 at 2:14 AM, Dominik Vogt > wrote: > > On Mon, Dec 13, 2021 at 12:22:47AM +, Hegel3DReloaded wrote: > > > > Is this has something to do with intensive work you and Thomas did > > > couple weeks ago with new parser? > > > > Yes, I fixed a leak at the cost of introducing a crash. > > I see. It is working now. May I close > https://github.com/fvwmorg/fvwm3/issues/647 Ye, please. > or you will do it with some description FTR? Only if forced to. I'm not good with web tools. :-) Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Monday, December 13th, 2021 at 2:51 AM, Dominik Vogt wrote: > I've committed a patch to master that truncates out of range sizes > and positions to the max/min values instead of rejecting them. Yes, it is ok now. > Is there anything else in your config that's out of range? The X > protocol is limited to 16 bit values for positions (signed) and > window sizes (unsigned). I.e. -32768 to +32767 and 0 to 65535. It appears that on "Restart" Front Panel ends up in the +0 +0, upper left corner of the screen. It starts ok, it is placed at the bottom center part, but something relocates it in the last moment. I remember we had this problem often introduced and then fixed again. Now it seems that "All (FrontPanel,CirculateHit) PlaceAgain" is causing the problem. That is, it behaves differently that on fvwm3 1.0.4 and fvwm 2.6.9. It looks like PlaceAgain is ignoring Style for panel: PositionPlacement $[infostore.frontpanel.pos.placement] ... where infostore.frontpanel.pos.placement is "screen c 50-50w -0p ewmhiwa" hardcoding this in styles instead of infostore variable doesn't change this. A bit of more diagnostic: If I execute PlaceAgain with FvwmCommand from terminal in this branch, Front Panel (FvwmButtons) ends up on +0 +0. If I execute "Move screen c 50-50w -0p ewmhiwa" it ends up where it needs to be. > -32768 is probably the better choice for "out of view" windows. > Fvwm doesn't use negative coordinates. Thanks, I will make it like that. Now if I can only remember what I need to test, and what behaviour to expect from the FvwmPager. :-) I have set it up on two monitors now, and it looks consistent on the both screens with and without "Monitor" setting. When without "Monitor" setting, it shows both screens and it is horizontaly wide. I have tried with DeskTopScale too, it is ok. -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Monday, December 13th, 2021 at 2:14 AM, Dominik Vogt wrote: > On Mon, Dec 13, 2021 at 12:22:47AM +, Hegel3DReloaded wrote: > > Is this has something to do with intensive work you and Thomas did > > couple weeks ago with new parser? > > Yes, I fixed a leak at the cost of introducing a crash. I see. It is working now. May I close https://github.com/fvwmorg/fvwm3/issues/647 or you will do it with some description FTR? -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Mon, Dec 13, 2021 at 12:32:53AM +, Hegel3DReloaded wrote: > On Monday, December 13th, 2021 at 1:18 AM, Dominik Vogt > wrote: > > On Mon, Dec 13, 2021 at 12:12:30AM +, Hegel3DReloaded wrote: > > > > "Move +32768p +32768p", > > > Side note: The maximum valid position is +32767p +32767p. This > > probably wraps around to -32768. > > That's it! If I redefine this to +32767p +32767p it starts to work as > expected. > This will probably be ok to change no matter if used with FVWM 2 or FVWM 3. > Something has changed in the new code apparently. I've committed a patch to master that truncates out of range sizes and positions to the max/min values instead of rejecting them. Is there anything else in your config that's out of range? The X protocol is limited to 16 bit values for positions (signed) and window sizes (unsigned). I.e. -32768 to +32767 and 0 to 65535. > but never mind, reducing it to 32767 fixes it. -32768 is probably the better choice for "out of view" windows. Fvwm doesn't use negative coordinates. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Mon, Dec 13, 2021 at 12:22:47AM +, Hegel3DReloaded wrote: > > I'm not very happy with the "new" monitor handling code. It added > > potentially broken new parsing code all over the place. That > > should really be done in a single, well tested parser. At the > > moment we have a myriad of places where parsing is done, and its > > very tedious to even execute all code paths. > > Is this has something to do with intensive work you and Thomas did > couple weeks ago with new parser? Yes, I fixed a leak at the cost of introducing a crash. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Monday, December 13th, 2021 at 1:12 AM, Dominik Vogt wrote: > On Sun, Dec 12, 2021 at 11:46:05PM +, Hegel3DReloaded wrote: > > Sorry to say, but I even didn't have a chance to start after trying to log > > in. > > It crashes badly. Something to do with malloc and pointers. > > Should be fixed. We need test cases for all this parsing code. > > :-/ Since I'm using FVWM as a framework, my heaveweight configuration often triggers things. I'm not trying to promote my work, but having one VM with NsCDE and trying to run new FVWM code with it's setup can be a good "stress test". See my second mail on FvwmPager issue. It seems also as parsing issue: looks like window context for "Move" is lost. > I'm not very happy with the "new" monitor handling code. It added > potentially broken new parsing code all over the place. That > should really be done in a single, well tested parser. At the > moment we have a myriad of places where parsing is done, and its > very tedious to even execute all code paths. Is this has something to do with intensive work you and Thomas did couple weeks ago with new parser? -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Mon, Dec 13, 2021 at 12:12:30AM +, Hegel3DReloaded wrote: > On Monday, December 13th, 2021 at 12:46 AM, Hegel3DReloaded > wrote: > > On Sunday, December 12th, 2021 at 12:40 PM, Dominik Vogt > > dominik.v...@gmx.de wrote: > > > > The dv/pager-noaspect should work now, but I've not tested it with > > > multiple monitors. > > Now I have iteresting behaviour with my "Local" pager even before I started > to test: when Local pager does not posess pointer, it should disappear by > the means of > "Move +32768p +32768p", Side note: The maximum valid position is +32767p +32767p. This probably wraps around to -32768. > but instead of doing this, it changes > my pointer into cross, GeometryWindow appears, and expects from me to move > pager around! :-) Can you give me the relevant parts of the config and some instructions, please? > It seems to me it looses the window X11 resource context of "LocalPager" [1] > Schedule Periodic $[infostore.rootpagertimeout] 131313 All (LocalPager, > CirculateHit, !HasPointer, !State 6) f_HideLocalPager > https://github.com/NsCDE/NsCDE/blob/master/data/fvwm/Functions.fvwmconf.in Is that the config file? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Sun, Dec 12, 2021 at 11:46:05PM +, Hegel3DReloaded wrote: > On Sunday, December 12th, 2021 at 12:40 PM, Dominik Vogt > wrote: > > > On Sat, Dec 04, 2021 at 02:04:48PM +, Hegel3DReloaded wrote: > > >> Sounds ok. Which branch should I checkout to test this? > > > The dv/pager-noaspect should work now, but I've not tested it with > > multiple monitors. > Sorry to say, but I even didn't have a chance to start after trying to log in. > It crashes badly. Something to do with malloc and pointers. Should be fixed. We need test cases for all this parsing code. :-/ I'm not very happy with the "new" monitor handling code. It added potentially broken new parsing code all over the place. That should really be done in a single, well tested parser. At the moment we have a myriad of places where parsing is done, and its very tedious to even execute all code paths. > When we get pass this point, I will test the rest you wrote. BTW, I'm actually > using one big monitor, but when testing multiple monitors setup, I'm helping > myself with KVM/Qemu virtual machines with virtual monitors. The crash > mentioned above was still in a single monitor setup. I didn't get very far. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Monday, December 13th, 2021 at 12:46 AM, Hegel3DReloaded wrote: > On Sunday, December 12th, 2021 at 12:40 PM, Dominik Vogt dominik.v...@gmx.de > wrote: > > The dv/pager-noaspect should work now, but I've not tested it with > > multiple monitors. I have found temporary workaround to comment out definition of my complex function f_SetFvwm3NonGlobalBackground[1] which triggers this crash. Now I have iteresting behaviour with my "Local" pager even before I started to test: when Local pager does not posess pointer, it should disappear by the means of "Move +32768p +32768p", but instead of doing this, it changes my pointer into cross, GeometryWindow appears, and expects from me to move pager around! :-) It seems to me it looses the window X11 resource context of "LocalPager" [1] Schedule Periodic $[infostore.rootpagertimeout] 131313 All (LocalPager, CirculateHit, !HasPointer, !State 6) f_HideLocalPager For a reference, everything work fine with latest 1.0.4 release, and 2.6.9. [1] https://github.com/NsCDE/NsCDE/blob/master/data/fvwm/Functions.fvwmconf.in -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Sunday, December 12th, 2021 at 12:40 PM, Dominik Vogt wrote: > On Sat, Dec 04, 2021 at 02:04:48PM +, Hegel3DReloaded wrote: >> Sounds ok. Which branch should I checkout to test this? > The dv/pager-noaspect should work now, but I've not tested it with > multiple monitors. Hi Dominik, Sorry to say, but I even didn't have a chance to start after trying to log in. It crashes badly. Something to do with malloc and pointers. I have opened issue here: https://github.com/fvwmorg/fvwm3/issues/647 When we get pass this point, I will test the rest you wrote. BTW, I'm actually using one big monitor, but when testing multiple monitors setup, I'm helping myself with KVM/Qemu virtual machines with virtual monitors. The crash mentioned above was still in a single monitor setup. I didn't get very far. -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Sat, Dec 04, 2021 at 02:04:48PM +, Hegel3DReloaded wrote: > On Sat, Dec 04, 2021 at 02:13:06PM +0100, Dominik Vogt wrote: > >> On Sat, Dec 04, 2021 at 02:03:46PM +0100, Dominik Vogt wrote: > > >> 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). > > >> Maybe something like this by default? > > >> desktopscale auto [max%] > > >> "auto" means to make the pager consume "max%" of the desktop width > >> and height. The default would be "auto 10" or something, so (a) > >> by default the pager autoscales and (b) it always consumes 10% of > >> the screen size in one direction and no more than 10% in the other > >> direction. > > > Experimental patch attached (only initial size calculation; no > > live resizing yet). > > Sounds ok. Which branch should I checkout to test this? The dv/pager-noaspect should work now, but I've not tested it with multiple monitors. By default, the pager uses no more than 25% of the screen size (the root window size) in both directions (and tries to maximize within these limits), i.e. the default is AutoScale 25 When the desktop is resized with the "desktopsize" command or by adding or removing monitors, the window is resized within the given limits to match the aspect ratio. (That happens even if the user has manually resized the pager window). Things to test: * When the pager window is created or the desktop layout changes, the dimensions of the *current* desk are used for size calculations. I'm not sure if there are unwanted effects if the pointer is on a different screen than the pager window when that happens. Is this still something one would have with Xrandr? * Multi-monitor setup with one screen, i.e. one fvwm manages all monitors. * Multi-monitor setup with multiple screens, a separate fvwm instance runs for each screen. * Add and remove monitors in each setup. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Sat, Dec 04, 2021 at 02:04:48PM +, Hegel3DReloaded wrote: > > Experimental patch attached (only initial size calculation; no > > live resizing yet). > > Sounds ok. Which branch should I checkout to test this? Try out dv/pager-noaspect. It contains more work to allow resizing the window when the desktop layout is changed, but it doesn't work yet. The resize_pager_window() call from list_new_page() doesn't work. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Sat, Dec 04, 2021 at 02:13:06PM +0100, Dominik Vogt wrote: >> On Sat, Dec 04, 2021 at 02:03:46PM +0100, Dominik Vogt wrote: >> 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). >> Maybe something like this by default? >> desktopscale auto [max%] >> "auto" means to make the pager consume "max%" of the desktop width >> and height. The default would be "auto 10" or something, so (a) >> by default the pager autoscales and (b) it always consumes 10% of >> the screen size in one direction and no more than 10% in the other >> direction. > Experimental patch attached (only initial size calculation; no > live resizing yet). Sounds ok. Which branch should I checkout to test this? -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Sat, Dec 04, 2021 at 02:13:06PM +0100, Dominik Vogt wrote:
> On Sat, Dec 04, 2021 at 02:03:46PM +0100, Dominik Vogt wrote:
> > 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).
>
> Maybe something like this by default?
>
> desktopscale auto [max%]
>
> "auto" means to make the pager consume "max%" of the desktop width
> and height. The default would be "auto 10" or something, so (a)
> by default the pager autoscales and (b) it always consumes 10% of
> the screen size in one direction and no more than 10% in the other
> direction.
Experimental patch attached (only initial size calculation; no
live resizing yet).
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
From f82e4ce6df30513d8073f8cda02525aa36ba3464 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Sat, 4 Dec 2021 14:49:58 +0100
Subject: [PATCH] Pager autoscale draft.
---
modules/FvwmPager/FvwmPager.c | 11 +--
modules/FvwmPager/FvwmPager.h | 3 ++-
modules/FvwmPager/x_pager.c | 26 --
3 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/modules/FvwmPager/FvwmPager.c b/modules/FvwmPager/FvwmPager.c
index 52199ce9..f0a60dd1 100644
--- a/modules/FvwmPager/FvwmPager.c
+++ b/modules/FvwmPager/FvwmPager.c
@@ -1792,7 +1792,8 @@ void ParseOptions(void)
FvwmPictureAttributes fpa;
Scr.FvwmRoot = NULL;
Scr.Hilite = NULL;
- Scr.VScale = 32;
+ Scr.Scale = 10;
+ Scr.do_autoscale = 1;
fpa.mask = 0;
if (Pdepth <= 8)
@@ -2257,7 +2258,13 @@ void ParseOptions(void)
}
else if (StrEquals(resource, "DeskTopScale"))
{
- sscanf(arg1,"%d",);
+ sscanf(arg1,"%d",);
+ Scr.do_autoscale = 0;
+}
+else if (StrEquals(resource, "AutoScale"))
+{
+ sscanf(arg1,"%d",);
+ Scr.do_autoscale = 1;
}
else if (StrEquals(resource, "WindowColors"))
{
diff --git a/modules/FvwmPager/FvwmPager.h b/modules/FvwmPager/FvwmPager.h
index 85805240..e371d4ed 100644
--- a/modules/FvwmPager/FvwmPager.h
+++ b/modules/FvwmPager/FvwmPager.h
@@ -70,7 +70,8 @@ typedef struct ScreenInfo
char *Hilite; /* the fvwm window that is highlighted
* except for networking delays, this is the
* window which REALLY has the focus */
- unsigned VScale; /* Panner scale factor */
+ unsigned Scale;/* Panner scale factor */
+ int do_autoscale : 1;
Pixmap sticky_gray_pixmap;
Pixmap light_gray_pixmap;
Pixmap gray_pixmap;
diff --git a/modules/FvwmPager/x_pager.c b/modules/FvwmPager/x_pager.c
index b2f22a62..a30fcf4f 100644
--- a/modules/FvwmPager/x_pager.c
+++ b/modules/FvwmPager/x_pager.c
@@ -695,10 +695,32 @@ void initialize_pager(void)
} else if (pwindow.height > label_h * Rows) {
pwindow.width = ((pwindow.height - label_h * Rows + Rows) *
vWidth) / vHeight + Columns;
+ } else if (Scr.do_autoscale) {
+ int w_raw;
+ float wf;
+ int h_raw;
+ float hf;
+ rectangle screen_g;
+ float f;
+
+ FScreenGetScrRect(
+ NULL, FSCREEN_CURRENT, _g.x, _g.y,
+ _g.width, _g.height);
+ w_raw = VxPages * vWidth * Columns + Columns;
+ h_raw = VyPages * vHeight * Rows + Rows;
+ wf =
+ ((float)w_raw) /
+ (screen_g.width * ((float)Scr.Scale) / 100.0);
+ hf =
+ ((float)h_raw) /
+ (screen_g.height * ((float)Scr.Scale) / 100.0);
+ f = (wf > hf) ? wf : hf;
+ pwindow.width = ((float)w_raw) / f;
+ pwindow.height = ((float)h_raw) / f;
} else {
- pwindow.width = (VxPages * vWidth * Columns) / Scr.VScale +
+ pwindow.width = (VxPages * vWidth * Columns) / Scr.Scale +
Columns;
- pwindow.height = (VyPages * vHeight * Rows) / Scr.VScale +
+ pwindow.height = (VyPages * vHeight * Rows) / Scr.Scale +
label_h * Rows + Rows;
}
}
--
2.30.2
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Sat, Dec 04, 2021 at 02:03:46PM +0100, Dominik Vogt wrote: > 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). Maybe something like this by default? desktopscale auto [max%] "auto" means to make the pager consume "max%" of the desktop width and height. The default would be "auto 10" or something, so (a) by default the pager autoscales and (b) it always consumes 10% of the screen size in one direction and no more than 10% in the other direction. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Sat, Dec 04, 2021 at 11:14:09AM +, Hegel3DReloaded wrote: > On Saturday, December 4th, 2021 at 11:39 AM, Dominik Vogt > 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
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Saturday, December 4th, 2021 at 11:39 AM, Dominik Vogt 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? 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. 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]". 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. -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Sat, Dec 04, 2021 at 10:09:34AM +, Hegel3DReloaded wrote: > Yes, there are some cases, or rather there > will be them in FVWM3 when it will approach the point where resolution > change, or new monitor addition will not mandate fvwm restart to get things > in place. In this case, FvwmPager can end up smaller or bigger than wanted. 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? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
I've committed two patches.
1) fac9eb945e442bebfb2612fed8edb68a9853a6ca
Removes minimum size, base size and size increment hints from the
pager. This change has not been disputed by anybody.
2) ff3afd31466f604ee5a3711486d1b1da2ee2b090
Also removes the aspect ratio hint. this patch could be reverted
separately from the other one.
I understand that not everybody is happy with that. Reasons for
this decision:
* Nobody who advocated the aspect ratio actually resizes pagers
or knows anybody who does. Thus, the usability gain remains
speculative.
* The aspect ratio has real, existing consequences on pagers
started by Fvwmbuttons:
(a) Swallowed pagers don't use up all available space,
(b) animation of pagers used as panels is broken ("sliding").
(* Resizing windows with aspect ratio has some usability problems.
these may become less important when "elastic paging" is
implemented.)
* There's a workaround for (a): Explicitly give the pager a
geometry string in its configuration.
Disadvantage: If the swallowed pager just uses the default pager
config or the same config as standalone pagers, the
configuration change is big. You have to create a whole new
module config block for the swallowed pager.
* No workaround is available for (b), and nobody had an idea how
to fix it and still have aspect ratio hints. Giving the pager
an explicit geometry deos not work for panels that are supposed
to use the default size.
(a) and (b) are real bugs that break my config.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Wednesday, December 1st, 2021 at 2:13 AM, Dominik Vogt wrote: > On Tue, Nov 30, 2021 at 02:51:49PM +, Hegel3DReloaded wrote: >> Maybe having ctrl+mouse-resize as I proposed above? > Okay, I can imagine rare cases when one wants to re-enforce a > multiple of the original aspect ratio, and I'd be fine with > another key combination to force it. However, what are we > supposed to do with windows with a legitimate, fulltime aspect > ratio like mplayer? It would be very inconvenient to have the a. > r. ignored by default. Unfortunately I see no working heuristics > to tell a "hard" a. r. from a "hint". Sorry, I got confused here. I thought this is exclusively about FvwmPager's behaviour. Not other cases (video players), where you rightly say that aspect ratio does make a sense. Yes, there are some cases, or rather there will be them in FVWM3 when it will approach the point where resolution change, or new monitor addition will not mandate fvwm restart to get things in place. In this case, FvwmPager can end up smaller or bigger than wanted. I think shift+mouse-move, or configuration option for preserving aspect ratio makes a sense. >> the are made big enough by dinamically following screen resolution, > Isn't that what everybody does - give it a good default size and > that's it? Well, for me, it is ok, but having in mind how many people with their original ideas of behaviour of things use FVWM, that is, FVWM's native user base are really demanding users, I can imagine someone using this on daily basis, and wanting to have it preserve screen size, not trying to do it manually as much as they can visually. > What kind of use case is that; someone thinks the current size is > too small and wants to make it 50% bigger? Or the pager is in the > way, and instead of closing, lowering, shading, iconifying or > sending it to some container one makes the window smaller? What is > so special about the pager that it I don't know if you sent this mail prematurely, or the crappy mail service's web that I choose cutted it here, but "pager that it" is the last I see from your text. :-\ To answer: You are right for the other case when pager is on the way. All actions you enumerated have more sense than resizing it. But the first one can really be the issue. I remember once, a year ago, I had debugging session with Thomas and shared my screen. Pager was important during this problem, because state if windows on multiscreen was not the same as in pager. In one moment, Thomas asked me can I make my "Local" pager bigger, that it will be easier to work. So I resized it. -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Tue, Nov 30, 2021 at 02:51:49PM +, Hegel3DReloaded wrote: > > The situation is: > > 1. It's implementation is more or less broken everywhere. => > > Nobody uses it. > > > 2. If the ratio is not close to 1, it's outright annoying or even > > unusable. Try this: > > > > desktopsize 50x1 > > FvwmPager > > all (FvwmPager) move 0 50 > > > a) Grab the top border and resize it by moving the pointer. > > => Maximum height stops around "WidthX412" because the width > > automatically grows bacause af the aspect ratio, but can > > not get bigger than 32767. > > BAD > > Since the ways of using FvwmPager are so different between people's ideas how > to set it up, I think that having the opportunity to configure keeping aspect > ratio makes a sense. Those who are using 50x1 DesktopSize will of course not > use that obviously, but people who use 2x2, 3x2, 2x3, 4x2 and similar and not > having it swallowed inside FvwmButtons may prefer to keep aspect ratio. There > can even be here a solution like in drawing programs: you press Ctrl or Shift > while resizing the object to keep aspect ratio, otherwise, it is free form. > > [...] > > > Summary: There are a lot of quirks and bugs. Is there any gain > > in usability to make up for this? > > Maybe having ctrl+mouse-resize as I proposed above? Okay, I can imagine rare cases when one wants to re-enforce a multiple of the original aspect ratio, and I'd be fine with another key combination to force it. However, what are we supposed to do with windows with a legitimate, fulltime aspect ratio like mplayer? It would be very inconvenient to have the a. r. ignored by default. Unfortunately I see no working heuristics to tell a "hard" a. r. from a "hint". > > > But in terms of configurability, I still think an option > > > where the user can decide to preserve the aspect ratio when resizing > > > the window or not allows the most freedom for users. > > > But why would anybody want that? Does anybody really use a > > standalone pager, and if so, ever resizes it? > > I'm using 3 kinds of standalone FvwmPagers > > - "Local" Pager - showing only the current desk > - "Desk" Pager - showing what is on the non-current desk I select on the > Front Panel > - "Global" Pager - all desks and pages > > They are floating semi-transient objects. That is, having them transient is > not enough for me, so they quickly disappear by Schedule if they don't posess > the pointer. > > I don't really resize them, :-) > the are made big enough by dinamically following screen resolution, Isn't that what everybody does - give it a good default size and that's it? What kind of use case is that; someone thinks the current size is too small and wants to make it 50% bigger? Or the pager is in the way, and instead of closing, lowering, shading, iconifying or sending it to some container one makes the window smaller? What is so special about the pager that it Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
Hi all, On Tuesday, November 30th, 2021 at 2:57 PM, Dominik Vogt wrote: > Still, what is the benefit of having an aspect ratio set? For a non-swallowed floating FvwmPager, I think it makes a sense that screen aspect ratio is preserved in it's smaller representation. Like: 16:10, 16:9, 4:3 etc ... For example, I like to use 4x4 matrix: 4 desks, 4 pages each. For removing constraint of minimal size, I agree that FvwmPager should not impose restrictions. 2-4 pixels maybe, but not 100x100. > The situation is: > 1. It's implementation is more or less broken everywhere. => > Nobody uses it. > 2. If the ratio is not close to 1, it's outright annoying or even > unusable. Try this: > > desktopsize 50x1 > FvwmPager > all (FvwmPager) move 0 50 > a) Grab the top border and resize it by moving the pointer. > => Maximum height stops around "WidthX412" because the width > automatically grows bacause af the aspect ratio, but can > not get bigger than 32767. > BAD Since the ways of using FvwmPager are so different between people's ideas how to set it up, I think that having the opportunity to configure keeping aspect ratio makes a sense. Those who are using 50x1 DesktopSize will of course not use that obviously, but people who use 2x2, 3x2, 2x3, 4x2 and similar and not having it swallowed inside FvwmButtons may prefer to keep aspect ratio. There can even be here a solution like in drawing programs: you press Ctrl or Shift while resizing the object to keep aspect ratio, otherwise, it is free form. [...] > Summary: There are a lot of quirks and bugs. Is there any gain > in usability to make up for this? Maybe having ctrl+mouse-resize as I proposed above? > > But in terms of configurability, I still think an option > > where the user can decide to preserve the aspect ratio when resizing > > the window or not allows the most freedom for users. > But why would anybody want that? Does anybody really use a > standalone pager, and if so, ever resizes it? I'm using 3 kinds of standalone FvwmPagers - "Local" Pager - showing only the current desk - "Desk" Pager - showing what is on the non-current desk I select on the Front Panel - "Global" Pager - all desks and pages They are floating semi-transient objects. That is, having them transient is not enough for me, so they quickly disappear by Schedule if they don't posess the pointer. I don't really resize them, the are made big enough by dinamically following screen resolution, but it will be nice if we can somehow keep aspect ratio in a sense: "this is my monitor in small". -- Miroslav
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Mon, Nov 29, 2021 at 01:02:04PM -0700, Jaimos Skriletz wrote: > If you set a geometry, *FvwmButtons: Geometry 100x100, the aspect > ratio hints do not get set (as in the default-config), and you can > resize the window to be any size. Yes, but that doesn't help for the FvwmButtons panel. The panel is just a normally sized FvwmPager. I don't want to tell it a geometry. It shall open with the standard size whenever used. > In conclusion, if the aspect ratio hints also go it won't affect me > directly. Still, what is the _benefit_ of having an aspect ratio set? The situation is: 1) It's implementation is more or less broken everywhere. => Nobody uses it. 2) If the ratio is not close to 1, it's outright annoying or even unusable. Try this: desktopsize 50x1 FvwmPager all (FvwmPager) move 0 50 a) Grab the top border and resize it by moving the pointer. => Maximum height stops around "WidthX412" because the width automatically grows bacause af the aspect ratio, but can not get bigger than 32767. BAD => Every time you try you get a different height: 412, 411, 330, 359 etc. BAD. b) Now make it smaller by resizing it downwards from the rop border. => When the top border comes close to the bottom border, the window shrinks really fast. CONFUSING => Assume you have reduced it to a tiny rectangle at the left side of the screen (xmag says its 58x5 pixels, incldung borders). Pull the border down further. The window jumps back to full size, from 58x5 to 9750x123 at the original position. VERY CONFUSING => Repeat that, but drag the pointer quickly up and down to the screen border. THe pager window ends up with a random height. BAD => If you're unlucky, while the window shrinks the top right edge may end up below the cursor. Fvwm will then automatically grab that corner for further resizing. VERY CONFUSING c) But things are even worse. Create a fresh pager and grab it by the lower left corner and try to resize it. => When the pager gets smaller, it quickly moves off screen. BAD => If you end the resize with the window off screen, it may be hard to retrieve it. BAD Summary: There are a lot of quirks and bugs. Is there any gain in usability to make up for this? > But in terms of configurability, I still think an option > where the user can decide to preserve the aspect ratio when resizing > the window or not allows the most freedom for users. But why would anybody want that? Does anybody really use a standalone pager, and if so, ever resizes it? Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Sat, Nov 27, 2021 at 4:11 PM Dominik Vogt wrote: > > On Sat, Nov 27, 2021 at 02:44:07PM -0700, Jaimos Skriletz wrote: > > > then FvwmButtons will resize to fit without preserving aspect ratio. > > FvwmButtons does honour the aspect ratio (see above). > If you set a geometry, *FvwmButtons: Geometry 100x100, the aspect ratio hints do not get set (as in the default-config), and you can resize the window to be any size. So it is possible to turn off the aspect ratio hints to work with FvwmButtons. > > At the time we chose to have it be disabled via just setting a > > geometry string vs having an additional option to turn preserving > > aspect ratio on/off. I would rather have an option to allow users to > > toggle this vs just disable it. > > I disagree. From experience, using the aspect ratio always annoys > the user when resizing a window. It's fine for initial size > calcualtions, but after that, leave it to the user. There are > rare exceptions like video players. It also causes uncommon > problems like with sliding, swallowing in FvwmButtons, or using > "maximize grow grow" in a script. > > Imposing limitations on the use of fvwm's modules is > not the fvwm way of doing things. FvwmPager is capable of dealing > with any geometry, like all other modules. > I agree that we shouldn't impose limitations, which is why I think this should be configurable (which it kinda is). That way the user can turn on/off the option that resizing the pager honors the aspect ratio of the screen or not. Though this should be something the user can configure via an option in FvwmPager vs we decide for them based on if they set a Geometry or not. > New patch attached -> no problem with 1x1 pixels even when the > desktop is 50x50. > I do like removing the size_inc hints, as there was a bug with these/base_size hints vs the aspect ratio hints. So removing the base size and size_inc hints would fix that. In conclusion, if the aspect ratio hints also go it won't affect me directly. But in terms of configurability, I still think an option where the user can decide to preserve the aspect ratio when resizing the window or not allows the most freedom for users. jaimos
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Sat, Nov 27, 2021 at 02:44:07PM -0700, Jaimos Skriletz wrote: > On Sat, Nov 27, 2021 at 1:59 PM Dominik Vogt wrote: > > > > From commit 601c5c294a6a48fd402fbfca02b62142796167eb > > > > >* Improved use of sizehints to set both minimum window size, and to > > > preserve aspect ratio when resizing the pager. The aspect ratio is > > > set to the initial size of the window unless the user sets window > > > size with the Geometry option. > > > > x_pager.c: > > > + sizehints.flags = (sizehints.flags | PAspect); > > > + sizehints.min_aspect.x = sizehints.max_aspect.x = window_w; > > > + sizehints.min_aspect.y = sizehints.max_aspect.y = window_h; > > > > I'm against this change. > > > > 1) It breaks sliding the pager from a panel button. > > 2) fvwm's module were always supposed to deal with any size, even > > 1x1 or 65535x65535. > Not strictly true, there are some size increment hints that force the > pager's size to be an integer multiple of the number of pages shown, > so each page has the same number of pixels. So there were already some > restrictions on the sizes it could be. Right. The whole sizehints can be removed, except the width, height, usposition and gravity. All they do is impose unnecessary limitations: * Nobody cares if the width is not a multiple of the number of pages. If the pager is 299 pixels wide and there are three pages, then two of them have 100 pixels assigned and one has 99. So what? * Base size: If the pager gets unusable below a certain size, then do not make it smaller than that if you don't like it. I do resize modules to a very small size to get them out of the way sometimes (mostly FvwmButtons). Twenty years ago I personally removed all limitations on pager size. It seems I missed the standalone limitations because I only have one in the pager. FvwmPager is abolutely happy with any geometry (although it doesn't look good if it doesn't have at least two pixels per page). It still displays useful information even if it's only one pixel high. :-) > > 3) It makes it virtually impossible to have the pager fill the whole > > allocated area inside FvwmButtons. > > Can FvwmButtons be fixed to better deal with this? 1) No. Sliding breaks aspect ratio by design. 3) It's not FvwmButton's fault, it just honours the requersted aspect ratio because it has to. Programs might behave badly if their hints are ignored. Fvwm's modules are always fine if their hints are ignored because they are written to be fine. > > I see no benefit in these new limits. Nobody resizes the pager > > manually, and insde FvwmButtons it's really harmful. Can I remove > > this please? (See attached patch.) > > This can currently be disabled by proving an initial Geometry (though > it needs to be bigger than some minimum size I recall like 100x100) That's the value in the sizehints, but fvwm ignores that anyway. To get the initial size it looks at the real window size, not at the hints. In reality it's only 1 pixel per displayed page, and even that's unnecessary. The drawing and page management code can deal with pages that have not even a single pixel allocated to them. Let's remove the lower limit too. > then FvwmButtons will resize to fit without preserving aspect ratio. FvwmButtons does honour the aspect ratio (see above). > At the time we chose to have it be disabled via just setting a > geometry string vs having an additional option to turn preserving > aspect ratio on/off. I would rather have an option to allow users to > toggle this vs just disable it. I disagree. From experience, using the aspect ratio always annoys the user when resizing a window. It's fine for initial size calcualtions, but after that, leave it to the user. There are rare exceptions like video players. It also causes uncommon problems like with sliding, swallowing in FvwmButtons, or using "maximize grow grow" in a script. Imposing limitations on the use of fvwm's modules is not the fvwm way of doing things. FvwmPager is capable of dealing with any geometry, like all other modules. New patch attached -> no problem with 1x1 pixels even when the desktop is 50x50. Ciao Dominik ^_^ ^_^ -- Dominik Vogt From 565d878e776ca2cc21d89c1ff05a6c9e36f5cf57 Mon Sep 17 00:00:00 2001 From: Dominik Vogt Date: Sat, 27 Nov 2021 21:57:29 +0100 Subject: [PATCH] Remove size and resize limitation from FvwmPager. The limits are unnecessary, and the aspect ratio gives FvwmButtons a hard time to accomodate the pager when swallowed. --- modules/FvwmPager/x_pager.c | 42 +++-- 1 file changed, 12 insertions(+), 30 deletions(-) diff --git a/modules/FvwmPager/x_pager.c b/modules/FvwmPager/x_pager.c index 4718cd56..b2f22a62 100644 --- a/modules/FvwmPager/x_pager.c +++ b/modules/FvwmPager/x_pager.c @@ -122,7 +122,7 @@ Window icon_win; /* icon window */ static int MyVx, MyVy; /* copy of Scr.Vx/y for drag logic
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Sat, Nov 27, 2021 at 2:44 PM Jaimos Skriletz wrote: > > This can currently be disabled by proving an initial Geometry (though > it needs to be bigger than some minimum size I recall like 100x100) > then FvwmButtons will resize to fit without preserving aspect ratio. > I think I made it seem like 100x100 was the minimum size, this was just some random suggestion (since it won't matter if FvwmButtons is resizing it). Minimum size is 1 + height of desk titles.
Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding
On Sat, Nov 27, 2021 at 1:59 PM Dominik Vogt wrote: > > From commit 601c5c294a6a48fd402fbfca02b62142796167eb > > >* Improved use of sizehints to set both minimum window size, and to > > preserve aspect ratio when resizing the pager. The aspect ratio is > > set to the initial size of the window unless the user sets window > > size with the Geometry option. > > x_pager.c: > > + sizehints.flags = (sizehints.flags | PAspect); > > + sizehints.min_aspect.x = sizehints.max_aspect.x = window_w; > > + sizehints.min_aspect.y = sizehints.max_aspect.y = window_h; > > I'm against this change. > > 1) It breaks sliding the pager from a panel button. > 2) fvwm's module were always supposed to deal with any size, even > 1x1 or 65535x65535. Not strictly true, there are some size increment hints that force the pager's size to be an integer multiple of the number of pages shown, so each page has the same number of pixels. So there were already some restrictions on the sizes it could be. > 3) It makes it virtually impossible to have the pager fill the whole > allocated area inside FvwmButtons. Can FvwmButtons be fixed to better deal with this? > I see no benefit in these new limits. Nobody resizes the pager > manually, and insde FvwmButtons it's really harmful. Can I remove > this please? (See attached patch.) This can currently be disabled by proving an initial Geometry (though it needs to be bigger than some minimum size I recall like 100x100) then FvwmButtons will resize to fit without preserving aspect ratio. At the time we chose to have it be disabled via just setting a geometry string vs having an additional option to turn preserving aspect ratio on/off. I would rather have an option to allow users to toggle this vs just disable it. jaimos
