Possible Fl_Pack resize regression from 1.3 to 1.4

[Robert Arkiletian]

On AMD64 Debian 13 Trixie machine installing libfltk1.3-dev (fltk 1.3.11) the code below correctly resizes button b1 both horizontally and vertically when the window is manually resized.

But if the 1.3 dev package is removed (including dependencies with 'apt autoremove') and then libfltk1.4-dev (fltk 1.4.3) package is installed then the code below does NOT resize the b1 button correctly as before. Instead b1 only resizes in one direction and the window or the pack resizes in both directions.

#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Button.H>
#include <FL/Fl_Pack.H>
 
int main() {
 Fl_Window *window = new Fl_Window(200, 200);
 window->begin();
 Fl_Pack *p = new Fl_Pack(0,0,200,200);
 p->type(Fl_Pack::HORIZONTAL);
 p->begin();
 Fl_Button *b1 = new Fl_Button(0, 0, 100, 0, "1");
 Fl_Button *b2 = new Fl_Button(0, 0, 100, 0, "2");
 p->end();
 p->resizable(b1);
 window->end();
 window->resizable(p);
 window->show();
 return Fl::run();
}

[Robert Arkiletian]

Forgot to mention, if I change the FL_Pack to an Fl_Group and explicitly state the size of the button widgets, then the resize correctly works again in FLTK 1.4.3.

Also note, I've tested this on both wayland and X11 with 1.4.3 and there is no change in the behavior. Desktop environment is KDE.

 

[Manolo]

Isn't the behavior seen with FLTK 1.4 what is expected given the documentation of Fl_Pack, as follows?

"The 'resizable()' for Fl_Pack is set to NULL by default. Its behavior is slightly different than in a normal Fl_Group widget: only if the resizable() widget is the last widget in the group it is extended to take the full available width or height, respectively, of the Fl_Pack group."

If I modify your test program setting the pack's resizable to b2 (instead of b1), the GUI appears to resize correctly

[Albrecht Schlosser]

On 2/25/26 08:37 Manolo wrote:

Isn't the behavior seen with FLTK 1.4 what is expected given the documentation of Fl_Pack, as follows?

Yes.

"The 'resizable()' for Fl_Pack is set to NULL by default. Its behavior is slightly different than in a normal Fl_Group widget: only if the resizable() widget is the last widget in the group it is extended to take the full available width or height, respectively, of the Fl_Pack group."

If I modify your test program setting the pack's resizable to b2 (instead of b1), the GUI appears to resize correctly

Correct.

However, to be precise (I checked the code and the commit history):

The documentation cited above by Manolo was added by me because it was missing in 1.3 docs. I took this part from a comment in the code and described what the code was intended to do (and what it did already in 1.3 *if* the resizable() widget was the last child.

Formally setting any widget as resizable() of Fl_Pack was undefined (or at least undocumented) behavior before FLTK 1.4. The only documentation in 1.3 states that the resizable() of Fl_Pack was initialized to NULL.

Unfortunately the special resize behavior of Fl_Pack was not completely honored in 1.3 because the Fl_Group::resize() was not overridden in 1.3. This was fixed in 1.4. The side effect in 1.3 was that Fl_Group::resize() was executed implicitly when resizing an Fl_Pack and this made the button b1 in the example program resize in 1.3 as observed by the OP.

Conclusion:

1. The correct behavior is documented since 1.4, and it is implemented as documented since the behavior of the resize() method is now correctly documented.
2. This implies that button b1 in the example program should not resize as expected by the OP because the resizable() is documented to be ignored - unless it's the last child.
3. The behavior in 1.3 can be considered a bug or at least undefined behavior.
4. Since the behavior in version 1.3 was not documented, the new behavior in version 1.4 does not represent a regression, but rather a bug fix.

That said, the OP (Robert) has a valid point: there is a behavior change between 1.3 and 1.4, i.e. existing programs would change their behavior when compiled with 1.4 vs. 1.3, but IMHO this can't be changed.

@Robert Arkiletian: Thanks for reporting this, anyway. I think we should add a note to the docs of 1.4 and higher to reflect this behavior change.

[Robert Arkiletian]

On Wednesday, February 25, 2026 at 6:03:50 AM UTC-8 Albrecht-S wrote:

...

Formally setting any widget as resizable() of Fl_Pack was undefined (or at least undocumented) behavior before FLTK 1.4. The only documentation in 1.3 states that the resizable() of Fl_Pack was initialized to NULL.

Unfortunately the special resize behavior of Fl_Pack was not completely honored in 1.3 because the Fl_Group::resize() was not overridden in 1.3. This was fixed in 1.4. The side effect in 1.3 was that Fl_Group::resize() was executed implicitly when resizing an Fl_Pack and this made the button b1 in the example program resize in 1.3 as observed by the OP. Conclusion:

1. The correct behavior is documented since 1.4, and it is implemented as documented since the behavior of the resize() method is now correctly documented.
2. This implies that button b1 in the example program should not resize as expected by the OP because the resizable() is documented to be ignored - unless it's the last child.
3. The behavior in 1.3 can be considered a bug or at least undefined behavior.
4. Since the behavior in version 1.3 was not documented, the new behavior in version 1.4 does not represent a regression, but rather a bug fix.

That said, the OP (Robert) has a valid point: there is a behavior change between 1.3 and 1.4, i.e. existing programs would change their behavior when compiled with 1.4 vs. 1.3, but IMHO this can't be changed.

Thanks for the detailed explanation. I will update my lessons for my students to reflect this behavior. BTW, while I'm posting, just want to say it's fantastic to have native wayland support now in 1.4.