Greg Ercolano wrote:
Looking at the code for Fl_Group::resize(), it tells children
to resize before updating its own size.
This is a problem if the children's resize() code wants to know
what the parent's new size is going to be.
Assuming there's a good
Albrecht Schlosser wrote:
I'm not _absolutely_ sure about this, but I'd consider this a bug
(calling Fl_widget::resize() after calling resize() for the children),
because it will be done at the - unconditionally - anyway. That means,
should read: ... it will be done at the end -
Albrecht Schlosser wrote:
Greg Ercolano wrote:
Looking at the code for Fl_Group::resize(), it tells children
to resize before updating its own size.
This is a problem if the children's resize() code wants to know
what the parent's new size is going to be.
Assuming
greg ercolano wrote:
Albrecht Schlosser wrote:
Greg Ercolano wrote:
Looking at the code for Fl_Group::resize(), it tells children
to resize before updating its own size.
This is a problem if the children's resize() code wants to know
what the parent's new size is going to be.
Albrecht Schlosser wrote:
Having said this, I think that FLTK 2.0 might be different, because of
its different resizing approach (isn't there a layout() method that is
called first ?).
Albrecht
In fltk2.0 resize() is not a virtual method, it just directly sets xywh.
layout() is a
Greg Ercolano wrote:
With the revised patch Fl_Group_resize_2.patch, everything seems okay
now. This one could be optimized, too, because the sizes() call at the
beginning wouldn't be needed, if there are no children. It's just for a
proof of concept...
I also added the equivalent patch
Looking at the code for Fl_Group::resize(), it tells children
to resize before updating its own size.
This is a problem if the children's resize() code wants to know
what the parent's new size is going to be.
Assuming there's a good reason Fl_Group doesn't
