DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending] Link: http://www.fltk.org/str.php?L1784 Version: 2.0-current Fix Version: 2.0-current I agree that the general problem "isn't so much to do with the labels as it is with the actual positioning of elements within a ScrollGroup". However, you wrote: "It should simply be a matter of working out where the original placement was and *properly* setting the clip region, rather than overwriting it." Unfortunately I don't think that it is that easy. First of all, it has nothing to do with clipping (setting the clip region), since this is fixed. The problem is to determine what the displayable portion of the scrolling region should be. The (outside) labels are only a symptom, because this is not defined properly, and FLTK (1.x and 2.0) assume that it ought to be the bounding box of all widgets (ignoring outside labels). I had the "padding" issue in my own application (FLTK 1), and I solved it by adding an invisible box. I believe that setting margins (top, left, right, and bottom) could be a working solution, so that the user could add padding as s/he likes. I came to the conclusion that your idea of saving the initial position and restoring it wouldn't work in the general case. First of all, you wouldn't be able to define padding at the right and bottom side, but sometimes this could be desirable. Secondly, it is possible to position widgets initially at negative coordinates relative to the ScrollGroup. Imagine using the ScrollGroup for displaying a single (boy with an) image that may or may not fit in the ScrollGroup. The initial position shall be centered. If the image is bigger than the ScrollGroup, then it would have to be positioned on negative x/y. Now imagine that you also want to add a label below, above, left or right of the image... If we don't want to measure all labels in the ScrollGroup (as I said above, and I wouldn't propose doing it), then we must either: (a) add user-defined margins/borders in all directions (around the bounding box as it is calculated now) or (b) tell the user to use invisible boxes (as documented now). Since the latter is also used for resizing (resizable()), I believe that (b) could be an acceptable solution, whereas (a) could be implemented easily w/o much overhead, but with ABI breaking extensions (this would not be a problem for FLTK 2, but for FLTK 1.3, since it is now to be released soon). In the long term I'd probably favour (a). BTW: lines 121-123 don't suggest much to me, since they are needed anyway to draw outside labels *between* other widgets, and the drawing is always done correctly. It's only the scrolling (calculating the bounding box) that is buggy, if you like to see it so. Link: http://www.fltk.org/str.php?L1784 Version: 2.0-current Fix Version: 2.0-current _______________________________________________ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
