[haiku-development] Re: z-order in input dispatching and drawing

  • From: Clemens <clemens.zeidler@xxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 06 Sep 2011 09:15:40 +1200

On Sun, 04 Sep 2011 04:33:12 +1200, <pulkomandy@xxxxxxxxxxxxxxxxx> wrote:


On 2011-09-03 at 17:57:30 [+0200], Stephan Assmus <superstippi@xxxxxx>
wrote:
"aView isn't added in front of any other view"

This "in the front" here implies z-order to me.

Anyway, I still don't see why we couldn't define an order on the views,
even if Be didn't. Beside the endless bikesheding on which side of the list
should be front, and which should be back, of course :).

The use case I have in mind is something like an MDI interface. For
example, a tool similar to Cortex but showing complex devices instead of
just nodes. Each device (VST ?) would have its own view to draw in, add
controls, etc. And they could be connected together to build a complex
effect.
With Z-Order, it's easy to handle the sibling VST-views, allow them to
overlap and make the active one topmost, almost like windows. Is there a
way to achieve something like this without z-order, and getting events at
the right place ?


I needed same functionality for ALM (Auckland Layout Model). The goal of ALM is to make a layout editable. In a special editing mode I'm using a transparent BView and put it on top (front most layer) of the ALM layout. In this view I draw all the editing elements, e.g. tabs or selected areas/views.

To handle user input I installed a message filter to catch all mouse events and redirect them to my target edit view. I also see no reason why not define a z order and dispatch events according to this z order. This would be more intuitive than an undetermined behaviour and make such "hacks" much easier. "Hack" might be even a bit to harsh, can imaging that in case of a cortex like app it really makes sense to use BView's rather than a home grown bitmap layer system.

Cheers,
        Clemens

Other related posts: