I feel configure events and requests are messed up

[Kristian Høgsberg]

2011/9/7 Giovanni Campagna <scampa.giovanni at gmail.com>:
> Il giorno mar, 06/09/2011 alle 22.54 -0400, Kristian Høgsberg ha
> scritto:
>> 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.
>
> Well, when it comes to window sizing, not just X but also Win32 and
> Quartz have explicit request on the window object for changing the size,
> and they acknowledge that when you receive a resize event, all buffers
> have already changed size. There is no way for application code to
> ignore a resize event (except that queuing another resize request) and
> in fact most applications ignore resize events altogether, focusing only
> the resulting paint/expose events.
>
>> > 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.
>
> Yes, but one thing is the toolkit always providing a buffer
> appropriately sized, because the protocol mandates so (and therefore the
> compositor woulp clip only if the protocol is violate), another is the
> client notifying application level code, that independently decides if
> he likes the new size.
> Currently, in X, Win32, Quartz (possibly other), drawing surfaces are
> always setup to clip client-side to the actual window size and there is
> no way to remove the clip, because the underlying buffer is already
> resized when the application is notified. In wayland, on the other hand,
> the buffer is not there until you call wl_egl_window_resize (see the
> other email about my position on wl_egl_window) and then make some GL
> call to allocate it.
> It should be explicitly forbidden to attach a new buffer of the wrong
> size. Synchronization on the user resize path should happen by delaying
> the attachment of the new buffer until it has been redrawn completely by
> app code.

You're arguing that Wayland is broken because EGL doesn't clip the
user size buffer to what the server thinks it should be, and insist
that we add more request and state to the protocol to enforce this?
Why? You're back to telling me how Wayland should work, without given
a concrete example of something that's not possible.  It's more
important that clients always know exactly that the buffer size of the
EGLSurface they're rendering to corresponds to the size of the window
they're rendering.  That's the main case, that's what all clients want
to do, and that's the part we need to get right.  We can control
"rogue clients", which seems to be your main concern, just fine either
way.

>> 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.
>
> Without the equivalent of WM_SIZE_HINTS, the compositor does not know
> what constraints a window may place on resizing, and therefore does not
> know what actions are allowed (for example, maximizing is not just a
> matter of a single flag: it may be allowed in certain work area
> configurations and not in other)

Sure, as I said, this is one area that hasn't been developed much so
far.  It doesn't seem like that conflicts with the core resizing
protocol though.

> When it comes to character cell resizing, mutter also draws a small
> window at the center of the resized one, showing "N x M". I'm not sure
> this should be moved to the client-side, but if we keep it in the
> compositor, we need the communicate character cells.

Yeah, we would need some kind of request there to let the client
communicate the "logical size" of the window when it attaches a new
buffer.

>> 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.
>
> Well, I've prepared a branch locally, that includes everything I think
> is needed for window management (including some niceties in the client
> side API, like automatic caching of properties). I can send out patches,
> but I think a public branch would be easier to review and discuss.

Yea, a branch in a repo is definitely easier at this stage, please
share the link.

As for caching properties, that's something the toolkit should do.
The Wayland protocol works by sending out events to describe the state
of the objects.  When you bind to a global object, the global object
will typically send out event to describe its state at bind time and
after that, when the object changes state.  There are now "getter"
requests in the protocol, the assumption is that all state will be
cached client side.  However, not in libwayland-client.so.  That
library is just the bare bones protocol implementation, with one
exception: the wl_display object.  The wl_display object caches the
list of global objects and that's all you need to boot strap any state
you're interested in.

Any toolkit is going to have its own objects that wraps and abstracts
out the libwayland-client.so objects and the toolkit should cache
object state there and use that to provide answers for entrypoints
like gdk_window_get_width().  And maybe that's what makes the client
side of Wayland confusing, since when you look at it, there is nothing
that keeps track of the size of a window.  But that part is supposed
to be in the toolkit and the point is then that the toolkit can decide
the size it wants to actually render at and then make sure that the
entire rendering stack below it agrees on that size instead of
resizing in response to resize events that may be out of sync with
what the toolkit has seen.

Kristian