All,
I need some help to decide what to do with STR #2130 [1]. (BTW: this
problem is the same for FLTK 1.3).
It turned out that some strange effects are due to a negative height of
the Fl_Pack widget!
Without going too deep into it (I'm still testing), I would like to ask
for your opinions how to handle _negative_ widget sizes.
Would it be sensible to assume that negative width and/or height means
the same as 0, and that the widget is thus invisible?
The culprit of the strange behavior is in this piece of code in fl_rect.cxx:
// does this rectangle intersect current clip?
int fl_not_clipped(int x, int y, int w, int h) {
if (x+w <= 0 || y+h <= 0 ) return 0;
// more checks following ...
This looks plausible at the first look (if we assume that x and y can be
less than 0, but w and h are always >= 0). This would mean that the full
widget is in negative window coordinates, and thus doesn't need to be drawn.
Now let's assume Y=50: the first expression becomes true if h is <= -50,
and that is why the strange behavior in the tests can be seen.
The negative width or height can be caused by the auto resizing of the
Fl_Pack widget within a Fl_Group (without calling init_sizes()), but
this shouldn't matter for now. I'm not sure if/how we can "fix" this in
the first place, calling init_size() can _not_ be done.
We would get much more reliable behavior if we assume that negative
width and height are the same as 0 width/height, and that such a widget
is invisible.
I changed the code to
// does this rectangle intersect current clip?
int fl_not_clipped(int x, int y, int w, int h) {
if (x+w <= 0 || y+h <= 0 || w<=0 || h<=0) return 0;
(........................^^^^^^^^^^^^^^^ added)
and this worked much more as expected.
Any comments?
Albrecht
P.S. Please see the demo pack.cxx and more in:
[1] http://www.fltk.org/str.php?L2130
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
