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)
Change History (18)
by , 14 years ago
Attachment: | buttons.png added |
---|
by , 14 years ago
Attachment: | ClockReplicants.png added |
---|
Look like the same problem. When clock replicants is intersected replicants drawing wrong.
comment:1 by , 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:3 by , 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 , 14 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Overlapping views is a programming error. Tracker should be smarter than this, agreed.
follow-up: 6 comment:5 by , 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.
comment:6 by , 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.
follow-up: 8 comment:7 by , 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).
follow-up: 9 comment:8 by , 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.
follow-up: 10 comment:9 by , 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.
comment:10 by , 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 , 14 years ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
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 , 10 years ago
Milestone: | R1 → Unscheduled |
---|
comment:13 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | reopened → assigned |
comment:14 by , 5 years ago
Proposed fixes:
Handling of intersected views that perform drawing outside of BView::Draw
seems to impossible without API change.
comment:15 by , 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 , 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.
Intersected buttons