7. XDG Shell Basics

Chapter 7 deals with the window (or surface) management.

We have the xdg_surface interface, a window-like surface obtained from an wl_surface.

(03-04-2021, 02:42 PM)movq Wrote: It’s like the relationship between a “drawable” and a “window” in X11, isn’t it?

Yeah, it seems like it. Except that xdg_surfaces are toplevel windows, while in X11 you can have non-toplevel windows down the hierarchy.

Instead of override-redirect windows which manage themselves, we have popups and the positioner interface.
Popups and toplevel winodws are the two kinds of XDG surfaces.
If I understood correctly, the configure and ack_configure event and request have the same semantic of the configure request and configure notify events on X11.

Toplevel windows have events related to minimization and maximization, setting titles and so on.
To create a XDG toplevel from a XDG surface we use the get_toplevel request of the xdg_surface interface.
The set_app_id request is what changing the window class property is to X11.
I don't know what are the semantic differences between an ID and a Class, but I think they are used to apply different management rules to different set of windows.

8. Surfaces in Depth

Chapter 8 deals with the intrinsics of the surface interface, their events/requests, etc.

Surfaces have a pending state, which is its state while being drawn, and an applied state, which is the state when the surface is commited and both server and client agree that it represents a consistent state.
There is also the initial state, which is related to the unmapped state in X11.

The compositor use the frame callback request to tell the client it is ready for a new frame.
With surface damaging, we can request the compositor to redraw part of a surface.

Subsurfaces are what subwindows are in X11.
They are constrained by the bounds of their parent surface, have az-order relative to each other, and have a origin for its position relative to the parent surface.

In wayland, thre is a scale factor attached to each output, and clients need to apply this scale factor to their interfaces.

9. Seats: Handling Input

We deal with input with the wl_seat interface.

Quote:The server sends the client a capabilities event to signal what kinds of input devices are supported by this seat (represented by a bitfield of capability values) and the client can bind to the input devices it wishes to use accordingly.

Depending on what inputs we have at our seat, we can use different requests and interfaces.

The introduction to this chapter also deals with input grabbing, one of the most misunderstood topics on X11.
On wayland, the server decides whether to accept the input grabbing for the client, so the client does not abuse it.

To use a input device, we first need to get it from the wl_seat interface. Then, events are send to it.

As movq, I only skimmed through this chapter.
But most of the concepts seem to be straight forward.