Chapter 10-12

XDG Shell in depth
Oh a mention of client-side decoration, finally.

The xdg_toplevel has states that can be updated, it knows it needs to
update them whenever it receives a configure event, then it sends back
an ack_configure when it's done updating them.
That's very much async!

Popups require a special object requested from the xdg_wm_base called
a xdg_positioner. That's weird.

Wayland clients are responsible for their own decorations, done through
an extension xdg-decoration.
You can request the compositor to take over and perform the interactive
move with the "move" request.
You can also specify resizing edges for a window and ask the compositor
to take over.

We clearly see from these chapters how the base protocols gets extended,
and it's through these countless and different extensions that we find
useful functionality. Though, I guess they aren't standard and so that
makes them non-portable.

Chapter 11 is missing but I guess this would go over a clipboard extension
such as wl-clipboard, found here: https://github.com/bugaevc/wl-clipboard
Or it could be implemented outside wayland through a dbus service.
Same for chapter 12.

Conclusion:
I think that after reading these chapters I get a better idea of what
Wayland is about. It's all based on defining the protocol before anything
else, and then generating wrappers for the protocol. That makes for a
clearly defined API of what's available.
There's a lot of juggling to get basic things going because of that,
asynchronicity everywhere. Also it seems that when the basic protocol
doesn't fit your case you are forced to use something outside, a specific
extension. Yet, the protocol that's already there seems fine.

I think at this point, I'd be comfortable reading the code of
libraries. I'd especially be looking for the ones that wrap-up all the
code that seems just to be there to fulfill the interfaces but would
mostly be expected to do the same thing everywhere.
I guess I'll start getting into what compositors are available and
test things.