Re: [MOD] STR #3352: Tiny window problem if child group larger than window

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.bugs  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: [MOD] STR #3352: Tiny window problem if child group larger than window Albrecht Schlosser Mar 01, 2022 top right image
 
[STR Closed w/Resolution]

Link: https://www.fltk.org/str.php?L3352
Version: 1.3.4
Fix Version: 1.4.0
Git Commit: 091712bea8ff5aab89f0f8483ca572c118ca5715


Summary of changes:

(1) 74dd5164d3da59c99efc451438091c6a40327e0b: first attempt (regression,
see GitHub issue #392)

(2) 39b5ae9e6e957582eddf16c86829d01473458e5d: documentation updates
according to (1)

(3) 091712bea8ff5aab89f0f8483ca572c118ca5715: new fix (see below),
documentation modified accordingly


The third commit changes internal calling sequences and goes back to the
original behavior as supposedly intended by the original author(s).

The key point in calculation of the default size_range() values is to clip
the resizable() widget to the bounds of the window as suggested by Matthias
in comment #10.

The "magic 100" is a plausible value: it is used as the lower limits of the
resizable() widget (width and height) if it is larger than 100 in any
direction. This makes the resizable() widget shrinkable and thus the window
resizable below its original size (the regression mentioned above was that
windows couldn't become smaller than their original sizes).

The old size calculation was broken only for already broken widget layouts,
i.e. if the resizable() widget was not entirely inside the window. The new
algorithm produces the same results as before if the resizable() widget
doesn't need to be clipped (backwards compatibility).

The previously documented but not implemented feature "If either dimension
of resizable() is zero, then that is also the maximum size (so the window
cannot resize in that direction)" has been implemented. The new
documentation clarifies this in much simpler wording:

"If either dimension of resizable() is zero, then the window cannot resize
in that direction."

Finally, this applies only to the default size_range() calculation, i.e. if
a resizable() widget has been set but size_range() has not been called. The
recommendation is to always call size_range() if a resizable() widget of
the window is set so the programmer has full control.


Link: https://www.fltk.org/str.php?L3352
Version: 1.3.4
Fix Version: 1.4.0
Git Commit: 091712bea8ff5aab89f0f8483ca572c118ca5715


Direct Link to Message ]
 
bottom left image   bottom right image
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.