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

[Pekka Paalanen]

On Mon, 06 Feb 2012 13:08:38 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> Pekka Paalanen wrote:
> 
> > As long as clients know nothing about the global coordinate system,
> > nothing about "remember position" can be completely implemented client
> > side. I expect at some point we would add shell protocol to achieve
> > "remember layout" somehow, but I very much doubt it will deliberatly
> > expose the global coordinate system to the clients.
> 
> I'm rather confused: I thought clients were well aware of the "global 
> coordinate system" in that the current transformation of their surface 
> is how it's location maps to the global coordinate system, and clients 
> are allowed to set this transform.

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.

> > The output choosing code in the server would likely take the surface
> > bounding box, and find the output where most of the surface is. This is
> > how it already works, when we choose which output to synchronise the
> > surface to.
> 
> Yes this is exactly what I want to enforce, by making sure the client 
> cannot send any information other than "this is the box it would be in 
> if not maximized, and I want it maximized". The client is not allowed to 
> choose the output except by giving the unmaximized location, so there 
> cannot be conflicting information when the compositor wants to maximize 
> a window.

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.

I can't make a judgement on that.

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

Protocol-wise, I don't see your concern as a problem.

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.

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.


Thanks,
pq