Invalid handling of intersected BViews.

[X512]

When I press button 2 button 3 pressed(see attached image) instead. button 2 created after button 3.

[X512]

Intersected buttons

[X512]

Look like the same problem. When clock replicants is intersected replicants drawing wrong.

[tangobravo]

BViews are not supposed to overlap. There is no concept of a z-order for sibling views, and the BeBook is quite clear that it's not supposed to be done IIRC (In your example you can probably add button 2 as a child of button 3 and it will work OK). For the replicant case, tracker should probably prevent overlapping replicants. I think the buttons bug is "invalid" though.

[X512]

Mayble this is enhancement.

[X512]

Overlapped views need for another task(editing documents). Buttons is just examples. Is it hard to implement this feature? Is it slow down drawing?

[axeld]

Overlapping views is a programming error. Tracker should be smarter than this, agreed.

[axeld]

For what it's worth, it's pretty expensive, as you cannot use the views bounds for lots of stuff anymore, but need regions instead (that you have to compute before).

Frankly, I don't see any use of this. If you need this for something, you should obviously not use BViews in that way.

[X512]

Replying to axeld:

Frankly, I don't see any use of this. If you need this for something, you should obviously not use BViews in that way.

I try to develop editing program with compound documents like Gobe Productive. In editor subdocuments are layered. (for example you can put text document on top of raster image). Probably need to implement own layered views for this task.

[bonefish]

Replying to axeld:

For what it's worth, it's pretty expensive, as you cannot use the views bounds for lots of stuff anymore, but need regions instead (that you have to compute before).

I'm curious, where is that the case exactly? For computing what view is at a point (e.g. under the mouse) one goes down the view hierarchy and then iterates through the siblings, anyway. Right? And computing which views intersect with the dirty region should be pretty similar. The redraw regions are already regions. I can't imagine anything else ATM.

Frankly, I don't see any use of this. If you need this for something, you should obviously not use BViews in that way.

The other GUI toolkits I know support overlapping siblings with the expected semantics and I do see use in that. E.g. for MDI-like interfaces or really any interface that allows the user to move view-like objects around with some freedom (Cortex apparently doesn't use BViews for nodes).

[axeld]

Replying to bonefish:

I'm curious, where is that the case exactly? For computing what view is at a point (e.g. under the mouse) one goes down the view hierarchy and then iterates through the siblings, anyway. Right? And computing which views intersect with the dirty region should be pretty similar. The redraw regions are already regions. I can't imagine anything else ATM.

You iterate through the siblings, but you currently know when to stop - you would either need to check all siblings, or use a region for this. When drawing the view list is iterated in the opposite direction, and this also would need to be changed.

Also, don't forget about transparent views.

The other GUI toolkits I know support overlapping siblings with the expected semantics

I wonder, what are the expected semantics? Which of the two views should be on top of the other? Always the latter?

and I do see use in that. E.g. for MDI-like interfaces or really any interface that allows the user to move view-like objects around with some freedom (Cortex apparently doesn't use BViews for nodes).

Replicants, as mentioned by X512, would actually also be another example. If you're keen to have it, feel free to reopen the ticket. Personally, I don't really see the need, but it would make BViews more flexible indeed.

[X512]

Replying to axeld:

I wonder, what are the expected semantics? Which of the two views should be on top of the other? Always the latter?

Views must be drawn in the same order, as it is stored in list.

From BeBook:

AddChild() makes aView a child of the BView, provided that aView doesn't already have a parent. The new child is added to the BView's list of children immediately before the named sibling BView. If the sibling is NULL (as it is by default), aView isn't added in front of any other view—in other words, it's added to the end of the list.

BeOS API actually support this feature, but it isn't implemented.

[bonefish]

Replying to axeld:

Replying to bonefish:

I'm curious, where is that the case exactly? For computing what view is at a point (e.g. under the mouse) one goes down the view hierarchy and then iterates through the siblings, anyway. Right? And computing which views intersect with the dirty region should be pretty similar. The redraw regions are already regions. I can't imagine anything else ATM.

You iterate through the siblings, but you currently know when to stop - you would either need to check all siblings, or use a region for this.

Assuming you're talking about finding the view under the mouse, I don't see where overlapping siblings would complicate things: You just iterate through the list in top to bottom order and can stop as soon you hit a view.

When drawing the view list is iterated in the opposite direction, and this also would need to be changed.

Depending on what "opposite direction" means. One would need to draw in bottom to top order.

Also, don't forget about transparent views.

I don't see any problem with those. As long as all siblings intersecting with the dirty region are drawn in bottom to top order that should just work.

The other GUI toolkits I know support overlapping siblings with the expected semantics

I wonder, what are the expected semantics? Which of the two views should be on top of the other? Always the latter?

Not sure, if all toolkits use the same order -- and it doesn't matter all much as long as an order is defined -- but I find the most natural one is index 0 == bottommost, max index == topmost. That complies with the expectation that adding a view without specific index adds it to the end of the list and on top of all previous siblings.

and I do see use in that. E.g. for MDI-like interfaces or really any interface that allows the user to move view-like objects around with some freedom (Cortex apparently doesn't use BViews for nodes).

Replicants, as mentioned by X512, would actually also be another example. If you're keen to have it, feel free to reopen the ticket. Personally, I don't really see the need, but it would make BViews more flexible indeed.

It's not that I'm particularly keen on having the feature, but I think it has its uses and so far you haven't convinced me that it is complicated to implement or will make things less efficient.

Replying to X512:

From BeBook:

AddChild() makes aView a child of the BView, provided that aView doesn't already have a parent. The new child is added to the BView's list of children immediately before the named sibling BView. If the sibling is NULL (as it is by default), aView isn't added in front of any other view—in other words, it's added to the end of the list.

BeOS API actually support this feature, but it isn't implemented.

That only says that there is a sibling list, but nothing about how it relates to drawing. In a different place the BeBook explicitly states that overlapping siblings are not allowed (or result in undefined behavior -- I'm too lazy to look up which).

[X512]

Reopen. Need to implement correct BView drawing and input handling. All modern already OS have it. If is will implemented BView will very powerful and simple OLE analog.

[X512]

Proposed fixes:

• ​https://review.haiku-os.org/c/haiku/+/2091
• ​https://review.haiku-os.org/c/haiku/+/2093

Handling of intersected views that perform drawing outside of BView::Draw seems to impossible without API change.

[smallstepforman]

This is still an issue hrev54503, especially when drawing intersecting views with alpha.

View1(green background) View2(red background) View3(image+alpha)

I'd expect view3 to have a red background, not green. I really dont feel like inventing my own scene graph just to layout overlapping view.

[X512]

There are some problems with overlapped views with background color or bitmap. Drawing background should fix that. Also if overlapping views are used, all drawing must be inside BView::Draw, using drawing commands outside Draw function will cause artifacts and it can't be fixed.