On 06/06/12 08:58, David Lopez wrote:
> But the problem was that the widgets (some of them lines) were drawing two or
> three pixels outside widget's dimensions (x,y,w,h), so I think that they did
> not receive the events to do the redraw.
Yes, it's interesting how that can create undefined behavior.
I think it's probably easier to see when one sets the new
Fl_Group::clip_children() flag to 1, so that it forces children
to be clipped when they're outside the parent group's xywh. eg:
#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Group.H>
#include <FL/Fl_Box.H>
#include <FL/Fl_Button.H>
int main() {
Fl_Double_Window win(300, 300);
Fl_Group grp(100,100,100,100);
grp.box(FL_BORDER_BOX);
Fl_Box box(80,80,100,100,"Box");
box.box(FL_UP_BOX);
box.color(FL_RED);
Fl_Button b1(190, 90,100,25,"Button 1");
b1.color(FL_RED);
Fl_Button b2(190,190,100,25,"Button 2");
b2.color(FL_GREEN);
grp.end();
//grp.clip_children(1); // UNCOMMENT TO ENABLE CLIPPING
win.end();
win.resizable(win);
win.show();
return(Fl::run());
}
You'll get undefined results if you leave the clip_children()
line commented out. But if you un-comment it, you'll get a more
accurate picture of what's going on, so that one can see where
the widgets go outside the parent, where events are ignored
and drawing artifacts can occur.
The reason clipping isn't enabled by default is partly backwards
compatible (IIRC, clip_children() is a recent addition), but also
to have default behavior be optimal for speed. Having clipping disabled
by default keeps the clipping stack from growing for each level of
groups one adds. A larger clip stack means slower drawing, since every
coordinate during drawing has to pass through the clip stack.
In general FLTK's defaults emphasize optimization.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
