[haiku-bugs] Re: [Haiku] #6246: Invalid handling of intersected BViews.
- From: "bonefish" <trac@xxxxxxxxxxxx>
- Date: Wed, 30 Jun 2010 16:32:16 -0000
#6246: Invalid handling of intersected BViews.
---------------------------------+------------------------------------------
Reporter: X512 | Owner: axeld
Type: enhancement | Status: closed
Priority: normal | Milestone: R1
Component: Kits/Interface Kit | Version: R1/alpha2
Resolution: invalid | Keywords:
Blockedby: | Patch: 0
Platform: All | Blocking:
---------------------------------+------------------------------------------
Comment(by bonefish):
Replying to [comment:8 axeld]:
> Replying to [comment:7 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 [comment:9 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).
--
Ticket URL: <http://dev.haiku-os.org/ticket/6246#comment:10>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
