[PATCH] protocol: Add a request and event to identify the visible area for a surface

[Bill Spitzak]

Kristian Høgsberg wrote:

> It's done this way so that the compositor can provide the biggest
> possible visible area for the rectangle of interest.  If your main
> surface is rotated, the edges of the screen are at an angle with the
> window edges.  How do you define "the biggest visible area" in that
> case?  What if panels or other desktop elements form a non-rectangular
> region - we would have to return a very pessimistic "biggest
> rectangle", while a probe function like this will allow the compositor
> to intersect the proposed position against its internal geometry.

Yes you are right. What I was proposing would require the return of an 
arbitrary region, not just a rectangle. It would be nice to avoid having 
clients have to interpret regions, especially if the most common reason 
for them is rotation.

I now think an api that takes/returns rectangles will work. My 
worst-case scenario is a client that wants to popup a menu in a position 
so that every possible submenu is not clipped, except if there is no way 
to fit that arrangement into the visible area, in which case it needs to 
select a different positioning of the submenus and try again. At first I 
thought it needed the infinite potential bounding box of these submenus, 
but I now think it can just send a rectangle for every submenu. If one 
of them is clipped, it then has a good idea what direction to move the 
top-most menu. If that ends up clipped it knows that it has to choose a 
different arrangement of the submenus, such as moving the last one to 
the other side of it's parent menu. At first I was alarmed at the number 
of client/server round-trips this requires, but in fact a large batch of 
rectangles can be sent at once before waiting for the responses.

> I don't know what you're talking about, there's no automatic child
> surface positioning in shell and there never has been.  Please
> familiarize yourself with the protocol and code before posting.

Relevant part enclosed in asterisks from:

http://wayland.freedesktop.org/docs/html/protocol-spec-interface-wl_shell_surface.html

A.13.1.5. wl_shell_surface::set_transient - make the surface a transient 
surface
Map the surface relative to an existing surface. The x and y arguments 
specify the locations of the upper left corner of the surface relative 
to the upper left corner of the parent surface. **The flags argument 
controls overflow/clipping behaviour when the surface would intersect a 
screen edge, panel or such. And possibly whether the offset only 
determines the initial position or if the surface is locked to that 
relative position during moves.**

The code shows this has not been implemented, so I think this text 
should be removed from the docs.