Re: [g-a-devel] Wayland Migration: Getting the Z-Order of Top-Level Windows

[Matthias Clasen <matthias clasen gmail com>]

On Tue, Oct 15, 2013 at 9:58 AM, Piñeiro <apinheiro igalia com> wrote:

 

The question is: Where (by whom) should this be implemented? We have some initial thoughts on this:

1. Application toolkits should implement atk_component_get_mdi_zorder() for non-top-level windows. This is because the existing API [1] expects a return value that is relative to other components in the same container. Then AT-SPI2 would pass the z-order along to ATs through atspi_component_get_mdi_z_order(). [2]

2. For top-level windows, it becomes a bit trickier. During the Montreal Summit, Matthias suggested we could potentially get the information we've been getting from libwnck in X by adding new API to Mutter/Wayland. But upon further reflection we concluded that would not be sufficient. At least in the case of Orca and its users, we cannot assume Mutter (or X, or Wayland): Orca is being used in Unity, XFCE, and LXDE in addition to GNOME Shell.

For this reason,  we think the best way forward is for the toolkits to  also implement      atk_component_get_mdi_zorder() for top-level windows, as the toolkits know which environment (X, Wayland) they are in. In order for this to work, that new API on Mutter/Wayland would need to be available to those toolkits. But as we didn't get into too much detail during the Summit, we are not sure if that is possible. Is it? Other thoughts?

Hey,

I don't think atk_component_get_mdi_zorder is a good interface - its clearly a case of 'too much information' - you don't need the z order at all. What you need is just the 'component at the current pointer location'. It'll be much better to ask just for the information you need, instead of requesting a ton of frequently changing stacking information, and then doing costly post-processing on the client-side to find what you are actually after.

As for, making this information available to all clients - can't do that. It works in X just because X has no concept of separation at all. One of the selling points of Wayland is that it fixes this by not allowing clients to snoop out other clients windows or events. This interface would violate that, thus it has to be a privileged api that only accessibility tools get to use.

For xfce, lxde and other alternative X desktops, you can just keep doing what you've been doing under X all along. For mir, you have to talk to canonical...