[weston PATCH v6 1/2] add implementation for set_maximised

[Pekka Paalanen]

On Tue, 07 Feb 2012 11:50:22 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> Pekka Paalanen wrote:
> 
> > No, they are not. All the transformation work is purely server internal
> > and private. We could change to even more generic non-linear
> > transformations at will, nothing about it is in the protocol. This is
> > also what makes input transformations so easy, since for clients
> > everything is in surface-local coordinates.
> > 
> > This should have been obvious from the fact, that the surface
> > transformation patches never touched any protocol XML files.
> 
> A client is able to control the relative position of one surface to 
> another, however? That is required to make popup menus work.

Yes, at the time it sets the surface type to popup or similar, in the
current protocol. The key is "relative position", which is actually
interpreted as surface-local coordinates in the parent surface.

For example: http://people.collabora.com/~pq/menu-rotate.png

(Don't mind about the "rotate" or "scale" options in that context menu,
they are not implemented.)

> I have a problem with this idea, in that one of the surfaces is now 
> somehow the "master" and all the others are "children". This is the 
> start of the "Directed Acyclic Graph" that I have described before and 
> that I think it is important that Wayland avoid. The relationships 
> between windows is *extremely* complex and the best way to keep the api 
> to Wayland manageable is to insist that it remains on the client side..

But is there any way to realise a popup window, like a menu, without
saying that there is a single parent and the popup is relative to that?

> A simple example is the desire to have two "document" windows sharing 
> the *same* set of overlapping "toolbox" windows. Which document is the 
> "master"? What happens if the user wants to close it?

The toolbox windows would not be child windows of anything. Is there any
reason they should be children to other windows, like menus are?
You already sketched the raise protocol, that avoids communicating such
window relations to the server.

> > That's a good question, whether we should limit maximising to the
> > output the surface is already in, or could the client move it at will
> > to any specific output it chooses. In any case, the default action
> > would be to maximise to the output the surface is already in. That can
> > be either implicit as you suggest, or explicit by letting the client
> > know which output the surface would be in if it was mapped.
> 
> That will require the ability to put "unknown" into whatever field holds 
> the output of the surface.

The protocol core supports passing NULL instead of an object, like
output.


Thanks,
pq