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

Kristian Høgsberg hoegsberg at gmail.com
Mon Jan 28 17:39:14 PST 2013

On Mon, Jan 28, 2013 at 03:07:02PM -0800, Bill Spitzak wrote:
> It would be nice if there was a clear way to find out *all* the
> visible area. Right now it looks like I have to try a really large
> rectangle and just hope I have managed to cover all of the current
> output. It seems to me that getting rid of the rectangle and
> returning the result as though it was infinite in size would be
> simpler and cover what I would imagine a toolkit will actually do.
> Is there a reason for the rectangle?
> Another idea is to allow it to return a clip that is *larger* than
> the rectangle. This may be useful if the visible area is
> discontiguous: only the areas that intersect the rectangle are
> returned, and if none do then the "closest" one is returned. May be
> useful if a surface spans more than one output.

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.

> This should replace all the proposed automatic-positioning of child
> surfaces in the shell api. That was never going to work except for
> trivial popup modal questions. Real overlays want to draw graphics
> in both the overlay and main window pointing at each other, and
> popup in positions that use complex rules (like a submenu on the
> opposite side of a parent, or the parent menu shifted over so that a
> potential submenu can appear) that cannot be conveyed from client to
> server without the server becoming a program interpreter.

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.


More information about the wayland-devel mailing list