Today I wanted to spend some time making sure I wasn't getting too into the weeds and unintentionally overcomplicating some of my classes and inheritance from QtWayland. It was recommended that I take a look at Plasma Desktop's compositor KWin, as it is written in C++ and leverages QtWayland. Specifically in KWin I looked at their:

1. FrogColorManagement protocol implementation header and client code
2. Wlr Data Control protocol header and client code
3. KDE AppMenu Manager protocol header and client code

A couple key learnings from it:

1. I should really be putting my definition of QObject* parent = nullptr at the end of my constructors, it'll make specifying the constructor args nicer since I won't always be starting with noise of nullptr
2. I could probably get away with specifying a static protocol version rather than using wl_proxy_get_version. I am sure there are arguments for both, but I don't expect to be supporting many versions of a given protocol, assuming they were to exist, in the foreseeable future. knock on wood

Thanks for the readable code, KWin developers! It is much appreciated 💯 I wasn't really able to draw any clear conclusions on whether or not I am particularly overcomplicating my use of QtWayland, but I did take the opportunity to review my class constructors. I was able to at least simplify by constructor for WaylandOutputHead and I'm hoping with some more tinkering I can do the same to my WaylandOutputConfiguration which inherits from QtWayland::zwlr_output_configuration_v1. Afterwards, I spent some time implementing a configure method on my head class to construct and return a new configuration class. There isn't much involved in creating it as it is mainly around our internal reference to the ::zwlr_output_head_v1, however in places like the DBus server I will be using it regularly. One method call instead of repeating three lines over and over again? Yes please. Same deal in the configuration class as well, I implemented an enable method that creates a QtWayland::zwlr_output_configuration_head_v1 so that way I can take advantage of simpler methods for performing actions like position setting. Speaking of which, I took that stuff into use and started sorting out the configuration in my DBus server methods, starting with SetPosition. I think my next step will be to implement a function on my output orchestrator or manager that will create dummy configurations for any output that doesn't match a given serial. The reason for that is it is a protocol error to only specify the configuration of one head at a time. So if I change the position of a head, I must also inform at the same time that all other heads are either enabled or disabled. 🤷 Having a function that does all of that will hopefully keep my DBus server code much more concise and not prone to so much repeat protocol noise. Last thing I did development wise is a bit meta, which is added a Bluesky / Mastodon / Threads "call-to-action" at the bottom of all my Today's Dev posts. Figured if folks were being direct linked to the blog (maybe that is you, hi!) then they might not navigate to my homepage and see links to my socials. And with that, I'm off!