On Sat, Nov 27, 2021 at 1:59 PM Dominik Vogt <dominik.v...@gmx.de> 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

Reply via email to