7 XDG shell basics

So far, we’ve dealt with “display server stuff”, now we’re entering the realm of “window management”.

So, an `xdg_surface` is a `wl_surface` with the additional meaning of “this is a standard desktop window”. It’s like the relationship between a “drawable” and a “window” in X11, isn’t it?

The configure / ack_configure dance: This is how pending changes are finally “committed”.

`xdg_toplevel` finally is a “real” application window. There’s a clear object hierarchy, which is nice.

Oh, so there’s an “app ID”. Is this the equivalent of X11’s “WM_CLASS” property? Is this what wayland window managers will use to apply rules to windows? (An “ID” is something very different from a “class”, though. Hmm, we’ll see.)

And there’s the working example of a client. At the beginning, we set up a listener and then call `wl_display_roundtrip()`, which, I think, is a big misnomer. To me, “roundtrip” means: “We go back and forth once.” Like a roundtrip of an ICMP ping. But the manual page says:

Quote: int wl_display_roundtrip (struct wl_display * display)
Block until all pending request are processed by the server

This function blocks until the server has processed all
currently issued requests by sending a request to the display
server and waiting for a reply before returning.

So, this can be more than literally one “roundtrip on the networking level”, right? It’s actually something like “wl_display_process_pending()”?

This whole business of having 1000 objects and listeners and all that is something that I’ll have to get used to. As is the asynchronous nature of everything. I’m not super happy with it, yet. (And I’m also not convinced that so many things have to be asynchronous these days.) It’s clear and well structured, but it does make the code and the events harder to follow. At least that’s my initial impression of it.

It’s a bit strange that we draw the buffer in `xdg_surface_configure()`. More so, we first acknowledge the configure event and then draw? Maybe I’m too stuck in X11 terminology, where “configure” meant something else entirely? Is drawing unrelated to configuration anyway and we just use the “configure” event to know when a surface is ready to be drawn into?

Our window with the XOR pattern is shown on screen. But, there are no window decorations. So you’re telling me, the default is to have no decorations? What do I have to do to get them, implement another extension? Unfortunate. Or is this just a property of Weston?


8 Surfaces in depth

The moving XOR pattern introduces draw callbacks. That’s more like what I expected in chapter 7. Kind of. This callback fires for every new frame, which is required for animations/movies/games.

I’m not imaginative enough to understand why we need surface regions.

Wow, subsurfaces? At first, I thought this is very much not needed (this was once used in X11 a lot, but eventually abandoned because it was simply too convoluted). They give some good reasons for using them, but hmm … Not 100% convinced, yet.

Wayland provides HiDPI information per output now. How did that work in X11 again? My client had to manually query XRandR, right?


9 Seats: Handling input

Quote:A single input event from an input device may be broken up into several Wayland events for practical reasons.

Must be fun for toolkits to reassamble that stuff.

Quote:there is strictly speaking an uppercase version of 'ß', it's hardly ever used and certainly never typed

Hey, hey! I have an ẞ on my keyboard and it’s Shift+ß! (Okay, I admit it, I have a custom keymap.)

Okay, I admit that I only skimmed over this chapter. I find input handling to be mostly dull.