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

[Bill Spitzak]

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.

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..

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?

> 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.

>> Current X window managers split this information in unfortunately ways, 
>> requiring me to map an un-maximized window and then maximize it, often 
>> with an unavoidable on-screen glitch as the user sees the unmaximized 
>> size. My concern was that the client api allow both to be sent at the 
>> same time. Without this it is impossible for clients to save layouts 
>> with all the user's preferences such as what windows are maximized.
> 
> Do you mean that the output cannot be determined until we know the
> surface size, or something else?

What I mean is that (under both Gnome and KDE) to restore a window 
layout where a window is maximized, I have to show the window in the 
un-maximized state and then switch it to maximized. There is no other 
way to set the un-maximized size and position. This produces an ugly 
glitch when you launch the programs.

> We should be able to set everything for a surface before the initial
> attach (map), I agree on that. It should be quite easy, too, since the
> protocol sequence for a new surface from the client's point of view is:
> create, set type, set foo, set stacking, set whatever, [wait for
> configure event,] attach. All set state would become effective only at
> attach time.

If the client can set up everything so that the surface is maximized and 
that "un-maximization" will restore a size+position the client has saved 
before the first "attach" then I believe this will be glitch-free.

> I am still thinking about one surface at a time. If you want several
> surfaces with map happening simultaneously, I don't have ideas on how
> to nicely guarantee that. So far we would rely on the series of attach
> requests being processed in one go, which of course is not explicitly
> guaranteed. It might work in practice, though. I remember we had some
> discussion about this related to window stacking.

My proposal is that there is a "raise" command that has a number of 
surfaces in it. That defines a subset of surfaces that need attach 
commands before the atomic update.