Fabien Costantini wrote:
So my question here is would you agree/appreciate to see this API
in fltk 1.3 lib ?
I guess the question is how often this kind of code would be used?
FLUID could use it, just as fldiff does, but most applications
probably don't need it so I'm not sure it is
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
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1923
Version: 1.3-feature
This would contradict the FTLK OS transparent interface rendering
objective.
This said, it would be interesting to have such ' hide when
Presently we have 3 different targets only for ms visual development products,
considering the new msvisual 2008 tools, we should add another one..
This leads as it has been noted, to very hard build files management.
On one hand, cmake would avoid this difficulty, on the other hand, it is not a
