Opened 14 years ago

Last modified 4 years ago

#6246 assigned enhancement

Invalid handling of intersected BViews.

Reported by: X512 Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Kits/Interface Kit Version: R1/alpha2
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

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

Attachments (2)

buttons.png (687 bytes ) - added by X512 14 years ago.
Intersected buttons
ClockReplicants.png (1.6 KB ) - added by X512 14 years ago.
Look like the same problem. When clock replicants is intersected replicants drawing wrong.

Download all attachments as: .zip

Change History (18)

by X512, 14 years ago

Attachment: buttons.png added

Intersected buttons

by X512, 14 years ago

Attachment: ClockReplicants.png added

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

comment:1 by tangobravo, 14 years ago

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.

comment:2 by X512, 14 years ago

Type: bugenhancement

Mayble this is enhancement.

comment:3 by X512, 14 years ago

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

comment:4 by axeld, 14 years ago

Resolution: invalid
Status: newclosed

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

comment:5 by axeld, 14 years ago

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.

in reply to:  5 comment:6 by X512, 14 years ago

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.

comment:7 by bonefish, 14 years ago

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).

in reply to:  7 ; comment:8 by axeld, 14 years ago

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.

in reply to:  8 ; comment:9 by X512, 14 years ago

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.

in reply to:  9 comment:10 by bonefish, 14 years ago

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).

comment:11 by X512, 14 years ago

Resolution: invalid
Status: closedreopened

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.

comment:12 by pulkomandy, 10 years ago

Milestone: R1Unscheduled

comment:13 by axeld, 8 years ago

Owner: changed from axeld to nobody
Status: reopenedassigned

comment:14 by X512, 5 years ago

Proposed fixes:

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

Last edited 5 years ago by X512 (previous) (diff)

comment:15 by smallstepforman, 4 years ago

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.

comment:16 by X512, 4 years ago

There are some problems with overlapped views with background color or bitmap. Drawing background manually 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.

Last edited 4 years ago by X512 (previous) (diff)
Note: See TracTickets for help on using tickets.