Am 08.07.2009 9:35 Uhr schrieb "Duncan Gibson" unter
<[email protected]>:
>
>> 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?
>
> FWIW. my first comment, without having investigated further, is that
> as long as we are consistently using platforms that all start with
> (0,0) in the top left corner, we should not allow negative height and
> width at all. I'm not even sure about allowing zero height and width.
>
> If the code currently allows it, is it handled consistently everywhere?
> What does it mean? An invisible widget? Where is the bounding box of a
> group containing such a widget? Let's keep the lid on this can of worms,
> keep it simple and work to the principle of least surprise...
Negative coorinates are easly possible, common, and valid. x and y can
become negative if a window is moved across the left or top of the main
screen. But even the right and bottom coordinate of a widget can be negative
with the widget visible, for example in a left-handed dual screen setup.
That is, the right screen has the OS Menu Bar, and the left screen then may
have negative coordinates.
To me, screen coordinates are always signed.
As for the width and height, yes, they can be negative. We have never
documented on what should happen in this case, so it is simply "undefined".
There are really only three possibilities:
- if width or height becomes negative, the widget behaves as if it was
hidden in every respect
- the widget draws just like usual, but flipped (graphically flipped, or
just shifted to the top left)
- we don't allow it
I would tend to the first solution, but that means tat we would have to
check all drawing and positioning functions and event handling for all
widgets! We would have to add code to cehk for the relatively unlikely
negative sizes everywhere.
So practically, light, and fast would be solution three (or two - no special
handling).
Matthias
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
