Rename View.Bounds to View.Viewport and add View.ContentSize to enable built-in content scrolling

[tig]

Originally posted by @BDisp in #3158 (comment)

[dodexahedron]

I'm a fan of this by the title at least. Will love to see it later when I get back to work on things again.

[BDisp]

@tig the moment we've been waiting for to decide has come for the scrolling feature on the ContentArea. We have to decide the appropriate name for both. One is the real Rect Bounds of the ContentArea (0, 0 , Width, Height) and the other is the setting of the ContentSize (could be the same as ContentArea.Size, bigger or smaller, in this case discussable) and thus the ContentOffset will be the ContentArea.Point or negative.
I'm also think the the ContentArea could be a sub-class of Adornment and leave the Bounds as is which is the available space.
What do you think?

[BDisp]

I only beg to you, pleaseee merge my PR's because I'm getting tired resolving conflicts all the time.

At least if you don't agree with some change, please say something on the respective PR. Thanks.

[BDisp]

I think the better name for the View.Bounds is only View.BoundsSize because the location is always (0, 0). Thus a View can have the follow adornments (Margin, Border, Padding, Content or ContentArea). I think Content is the best option because it will have the Size BoundsSize property with the real available size and the Rect ContentArea will have the location and size the user want to set.
I said the Content could be a sub-class of Adornment but also it could not be and leave it as it's currently on the View.
Writing this to not forget.

[tig]

I only beg to you, pleaseee merge my PR's because I'm getting tired resolving conflicts all the time.

At least if you don't agree with some change, please say something on the respective PR. Thanks.

I'll make that a priority!

[tig]

I think the better name for the View.Bounds is only View.BoundsSize because the location is always (0, 0). Thus a View can have the follow adornments (Margin, Border, Padding, Content or ContentArea). I think Content is the best option because it will have the Size BoundsSize property with the real available size and the Rect ContentArea will have the location and size the user want to set. I said the Content could be a sub-class of Adornment but also it could not be and leave it as it's currently on the View. Writing this to not forget.

I have a (potentially unfounded!) bias against having another layer of View in the "content area". Perhaps this is from the trauma of dealing with ContentView, so the idea of Content being a subclass of Adornment does not resonate.

However, I love the Margin, Border, Padding, ContentXXX taxonomy. The only question in my mind is what XXX is.

a) XXX = ''
b) XXX = Area
c) XXX = Rect
d) XXX = Size
e) XXX = Dims

I vote for either Area or Rect for now because of

• #Create new ScrollBar based on a new Scroll and remove ScrollBarView/ScrollView #2489 - If I'm right about this, then we'll want ContentArea.Location to not always be 0, 0. If I'm wrong, we can easily change ContentArea to ContentSize/Dims later.

Good topic for continued debate though!!!

[BDisp]

I have a (potentially unfounded!) bias against having another layer of View in the "content area". Perhaps this is from the trauma of dealing with ContentView, so the idea of Content being a subclass of Adornment does not resonate.

I also think we don't need to have more Adornments. Only one more property and change Bounds to BoundsSize which is always the real size inside the Margin, Border and Padding as Size type. Adding a new property called ContentArea which must be a Rect type because this is the user setting location and size and must be used to draw to the screen on the clip area (Point(0, 0), BoundsSize). Thus you don't need to have the trauma because it's only one View with two properties and you only need to set the clip area to the ContentArea. While the location sides are negative and location sides more the BoundsSize are greater the clip size, no rune is added to the buffer Maybe is a good idea to create a new struct to be used on parameters which uses all this values in one type only:

Size BoundsSize
Rect ContentArea

However, I love the Margin, Border, Padding, ContentXXX taxonomy. The only question in my mind is what XXX is.

a) XXX = '' b) XXX = Area c) XXX = Rect d) XXX = Size e) XXX = Dims

I vote for either Area or Rect for now because of

Only if it's really necessary one more Adornment sub-class which I think may be not. I vote for the BoundsSize and ContentArea or ContentRect. Size and Dims aren't appropriate because we need the location

• #Build scrolling into View #2489 - If I'm right about this, then we'll want ContentArea.Location to not always be 0, 0. If I'm wrong, we can easily change ContentArea to ContentSize/Dims later.

Good topic for continued debate though!!!

You mean to continue this debate there? I think so because this is crucial if we want all the views can have built-in scroll bars.

[BDisp]

Size BoundsSize or Size ContentSize
Because it's all related with the Content area.

[dodexahedron]

I agree @tig that naming should be same as or similar to existing standard nomenclature, and do like the Padding, Margin, Border, etc naming better than Bounds, Frame, etc as was here before.

I like the way WPF handles it, with Margin, Padding, and Alignment to control layout and dimensions, too. Maybe inspiration can be acquired from something over there?

https://learn.microsoft.com/en-us/windows/apps/design/layout/alignment-margin-padding