boundingRect and scrolling

[monte]

Hi

I'd like to be able to have group object clipping with otherwise the behavior of groups lock location true. I experimented with boundingRect but scrolling isn't supported so that's not going to work. I made a small change to effectively use the F_BOUNDING_RECT flag as a way to give a group lock location like behavior and it worked nicely. However, I think it could be too significant a change to the way boundingRect currently works even though I think it's much more useful. I'm not sure I understand why boundingRect wasn't implemented as a boolean property clipsToBounds/Rect. How do you use it for anything else? Perhaps we can add a new flag and possibly deprecate boundingRect?

Cheers

Monte

[LCMark]

The boundingRect property allows you to set the content rect of the group - the rect of the group is then the view into this content rect. So, if the boundingRect is larger than the rect and you have scrollbars, you can scroll.

We have the following properties that affect group behavior:

• The rect
• Scrollbar visibility
• The boundingRect
• The lockLocation

So, lockLocation set to true means the group's size / location will not change to fit contents.

If the boundingRect is set, then it gives the content rect of the group, the rect of the group then becomes a window onto this content rect which is used to calculate the scrollbar positions / size if they are visible.

If there are no scrollbars, no boundingRect and lockLocation is set then object's within will be clipped to the rect of the group.

If there are scrollbars, no boundingRect and lockLocation is set then content rect is taken to be the bounds of the child controls but located at the top-left of the group.

At least, this is my interpretation of the current apparent action of these properties.

It's not clear to me what behavior you are proposing exactly - perhaps you could clarify?

[monte]

The behavior I want is exactly what lockLocation gives us but I want the group to be user resizable... Custom control.

[LCMark]

Gotcha - so essentially the group's rect should be the window on the rect of the controls within it.

How about this for behavior:

1. The rect of a group is always set by the rect property (or by sizing handles in pointer mode).
2. The content rect is taken to be:
   • if boundingRect not set - the union of the bounding rect of the children and the rect of the group
   • if boundingRect is set - the union of the boundingRect and the rect of the group
3. Whenever controls move within the group and boundingRect is not set, the content rect is updated appropriately
4. Whenever the group's rect is translated, the controls are translated with it
5. The scroll values of the group scroll over the width / height of the content rect
6. The formattedRect returns the boundingRect if set, otherwise the bounding rect of the children
7. The effective formattedRect returns the content rect

The reason for point 2 needing to union rectangles is to handle the case where the bounding rect does not cover the rect of the group. Without this, there isn't a way to calculate the range over which the scrollbars should scroll.

It might be useful to be able to specify to use the effective rects of children rather than just the rects, although this would require a fair bit of work to put in 'effective rect' changed notifications up the object hierarchy so perhaps could be something for later.

Of course, this still leaves the question as to what property should enable the above semantics, overriding the current hotch-potch that exists...

[monte]

A simple clipsToRect boolean would do the job wouldn't it?

[LCMark]

Yes - a 'simple' boolean to turn make the group work like that is all that is needed... My above list was attempting to enumerate the semantics we should expect from it. The interactions of the current group properties are not entirely clear so wanted to make sure we knew what behavior we were aiming for. I suspect it will just come down to a few tweaks to the existing code.

[monte]

Yes I think it's just F_LOCK_LOCATION || F_CLIPS_TO_RECT

I haven't attempted anything because I'm not sure what the go is with adding new flags and file formats etc.

[monte]

I thought adding a new flag and having it save with the file would be complicated.. turns out that's not the case so...
https://github.com/runrev/livecode/pull/125