I feel configure events and requests are messed up

[Kristian Høgsberg]

2011/9/6 Giovanni Campagna <scampa.giovanni at gmail.com>:
> Il giorno mar, 06/09/2011 alle 17.31 -0400, Kristian Høgsberg ha
> scritto:
...
>> Maybe you should introduce yourself and what you're working on before
>> threatening to break protocol?  I don't know what you're trying to do.
>
> Right, sorry, I should have done it before. Sorry also if my wording has
> been strong so far, but my reading of the first reply was "it is better
> like this, and we will never ever change it", even if X11 has done to
> opposite for more than 20 years, with fairly good results (at least on
> the management side).

X has certainly been around for a long time, but that doesn't mean
that the way it does it is the only way it can be done.  But more
importantly, Wayland is fundamentally different in a few key areas
that affect window management: the window manager is built into the
display server, we're always compositing and rendering happens client
side.  So for a start, there are only two processes involved in window
management (the compositor and the client) vs X server, WM and client.

> Anyway, I'm working on porting Mutter to Wayland,

Awesome, happy to hear that.

> and in various parts
> the current X11 code base assumes that it can resize to whatever size it
> likes, and that ConfigureRequests from other clients are just that,
> requests, not orders.
> There is a fair amount of code (dating back to previous century for a
> big part) dealing with correctly sizing windows, in presence of
> constraints, struts, particular user operations, etc. and the window
> manager simply expects that windows won't get in the way (or if they do,
> they do very clearly with WM_NORMAL_STATE, so the WM knows it).
> For example, if the window won't maximize, Mutter will desensitize the
> maximize item in the window menu and the maximize button in the title
> bar, as well as not showing the light blue overlay when dragging to the
> top, and same for edge tiling. All this is not possible if the final
> decision is in the hands of clients, rather than the compositor.

Again, I don't see specifically what it is here that you can't do with
the current protocol.  The compositor can resize a surface to whatever
size it wants, independent of the client.  This is something that
under X would happen between WM and X which is why X has those
requests, but in Wayland, it all happens internally in the compositor.
 And I think you're overlooking that even on X, resizing a window is
always a cooperative affair between the WM and client.  The client
always make the final decision on what it renders into the window, no
matter what size you insist the window is.  If you try to force a
window to be a different size than what the client thinks it should
be, on Wayland as well as X, you will have to "make up pixels", ie pad
with a background color or similar hacks.  Under X, the X server will
do that for you with the automatic rendering, under Wayland you have
to hack it in the compositor.  But the point is, you should never have
to do that, the client should always provide you with a buffer at the
size you ask for instead.

As for all the struts and snapping logic during resizing you mention,
what problem do you see there?  It should all work with Wayland as
well; the compositor grabs the pointer when resizing, looks through
all its constraints and then figure what size it thinks the window
should be, then sends the configure event to the client to ask for a
buffer at that size.  The client will typically provide that, but the
client has the option to provide a smaller buffer, in case it wants to
enforce resizing constraints such as character cell resizing or aspect
ration or even custom constraints.

Finally, wl_shell is far from complete.  It's intended to encapsulate
the interactions desktop clients have with a desktop shell (ie,
traditional linux desktop scenario) and play the same role for Wayland
as EWMH does for X.  For example, the maximize capability you mention
needs to be communicated so that when moving the window, mutter will
know whether or not to show the blue overlay.  And many other things
such as window title and window icon.  I've just not tried to tackle
that, since I don't want to specify that protocol, unless I'm also
implementing it.

>> >> 2. There is a compostitor->client call that says "the user is trying to
>> >> resize the window to be like this". The compositor assumes the client
>> >> will respond with the above resize call, or something similar (ie the
>> >> client can fix the call to round the call the increments and aspect
>> >> ratios and any other rules it wants).
>> >
>> > And this call is wrong. The compositor shouldn't ask, it should notify
>> > that something is changed. Window sizes are server state, and should be
>> > treated like that (including the possibility to change at any time).
>>
>> I think this is where some of the confusion comes from.  In Wayland,
>> windows don't change size without the client being involved.  You
>> can't meaningfully resize a window without the client rendering new
>> content.  The compositor can draw an outline as it resizes the window
>> and only send the configure event to the client once the resizing is
>> done, but you can't render the window at a different size without the
>> client providing the content.
>
> Again, I think rendering a window has nothing to do with configuring a
> window. You can stop updating the window in the compositor, but you need
> some why to tell client and server state that the window size is
> changed, even if the buffer is stale. Otherwise you're stuck with this
> mess in which the real window size is taken from the size of the last
> attached buffer...

Resizing a window requires repainting the window at the new size.