Sorry for not posting during the weekend, I had to stay home with gramps taking care of him and had almost no time.

Chapter 10 continues the topic on the XDG Shell.

Quote:Previously, we created a window at a fixed size of our choosing: 640x480. However, the compositor will often have an opinion about what size our window should assume, and we may want to communicate our preferences as well. Failure to do so will often lead to undesirable behavior, like parts of your window being cut off by a compositor who's trying to tell you to make your surface smaller.

I witnessed those undesirable behavior on X11. I forgot to communicate the size the wm set to the window back to the client, and drag-and-drop refused to work. I wonder if the same undesirable behavior occurs in Wayland.

The client can also request some constraints in the size of the window. This reminds me of the XSizeHints on X11.

Popups implement what in X11 is done with Override Redirect windows. While in X the client configures a override redirect window by itself, in Wayland it is the compositor who configures it using the positioner.

In xmenu I have to calculate the position of the menu relative to the monitor size so the menu is not mapped off the screen. I have to use Xinerama to query monitor information for that. On Wayland, it would be done by the compositor, not by the client itself.

Quote:This is used to allow the compositor to participate in the positioning of popups using its priveleged information, for example to avoid having the popup extend past the edge of the display.

Just like a X11 menu, a Wayland popup needs to grab the input. On xmenu I need to grab the input on the client side. Any client can grab the input. On wayland, it is the compositor who decides whether or not the client can grab the input, and in what conditions. I think it is a saner thing to do, otherwise a client can grab the input when not requested by the user. It is also the compositor who cancels the input grab (when the user presses escape or clicks outside of the popup). On xmenu, I have to cancel the grab manually on those conditions.

Then, the chapter goes to the topic of moving and resizing toplevel windows. On X11, there is a EWMH hint (_NET_WM_MOVERESIZE) for the client with CSD (client-side decoration) initiate the move or resize operation. On Wayland, this is done with a request. Again, like the popup input grabbing, the client needs to provides an input serial event to the compositor in order to start the interactive operation (so a client does not begin to move unexpectedly).

The chapter continues on the topic of CSD. On my window manager, I ignore any client-side decoration and draw the decoration on any window. I think that all windows should be uniformly decorated by the compositor/window manager.

The chapter is incomplete, as the section on positioners is missing the final part. Positioner is a topic I am really interested, because of xmenu.

Chapter 11 and 12 are also incomplete.

(11-04-2021, 01:56 PM)movq Wrote: It would have been lovely if the protocol encouraged splitting all this into different programs, I think. Something that manages the basic display functions, a window manager, a clipboard implementation, and so on. Like a micro kernel, not a monolithic one. You know, this has always been one of my favorite aspects of the Linux world: You can re-combine things. Wayland appears to make this a bit harder – but it’s out of scope of the book, and I’m just speculating anyway.

Funny enough, reading the book has not yet convinced me to jump on the Wayland bandwagon. Yes, atomicity. Yes, no “override redirect” hack anymore. But other than that? Alright, X11 carries historical baggage, lots of it (stippled lines, looking at you) … and we can never get rid of that if we still want to call it “X11”. That’s probably the issue. Still, maybe a stripped down implementation of X11 that only offers what we really need today? So that we don’t have to reinvent the entire wheel? Hmm. Maybe it doesn’t work that way. Maybe we need a clean cut.

That's also what I think of Wayland. I tend to combine different applications to compose my graphical environment (and I'm often writing such applications). I overuse the override redirect hack on my programs, as I said before, and they have to know things outside of the scope of the application (like using Xrandr/Xinerama to request the monitor size). Wayland makes it easier (or less hacky) to write such a menu application.