Just my two cents...

I presume the size_range() method is in the Fl_Window class only, because the windows driver provides support for its implementation at the window level. However, wouldn't most FLTK resize problems for users be more easily addressed if there were a size_range() method implemented under Fl_Widget, or at lesst, under Fl_Group? I believe other widget libraries provide for this in some fashion or another. Sometimes, it is hard for me to appreciate the "lightness" characteristic of FLTK when that means a lot of "heaviness" is placed on the back of the user in dealing with resize problems like the subject one, with all the tricky groups thing. I think a lot of us users just wind up subclassing the FLTK widgets to deal with resize issues and avoid the trickiness. Who knows how much redundant code has been written by all the FLTK users through the years to deal with resize, that could be assuaged to some degree more or less if FLTK itself had better built-in support.

Even if no size_range() were implemented, simply a flag with accessors in Fl_Widget to force the widget to remain fixed size on resize would be nice. Of course, most of us do that ouselves at some point, at the user level, for example in a widget "resize adapter" wrapper class. Such code is also available online via a search. But I think FLTK could/should easily internalize it -- why not? In the subject case, the B widget could be flagged as fixed size AND as the resizable widget for the top-level group/window. There is no contradiction, and I think it would yield the desired result.