With budgie-daemon v2 compiling and linking, today I tasked myself with hunting down the output head segfault I was getting and continuing forwards with the million other tasks I have. The segfault fix was dead simple. My construction of my WaylandOutputHead was simply incorrect as I wasn't specifying the new operator. Derp. So sorted that out, started digging into why my WaylandOrchestrator ready event wasn't firing. That was also pretty simple, during the construction of my WaylandOrchestator I was performing all the logic for getting the display, registry, adding the listener, and performing the dispatch. Well if the dispatch completes before you have the chance to connect up any callbacks for the emitted signal, guess what? You're not gonna obviously get any callbacks called for something that happened in the past. Duh, time doesn't work that way 😄 So I split out all that into an init method that I call after the construction of the orchestrator and setting up of connections. Voila, all sorted. After that, I cleaned up all the logging noise I wrote, a dead commented out function that was already implemented and used as a reference, then shifted my focus over to getting the DBus Server up and running for validating the state of my WaylandOrchestrator / Manager. Right now, I just have the DBus Server set to start in a callback once the orchestrator is ready, however I did take a look at the Qt6 Threads Technologies documentation to get some ideas on what to do for multi-threading. In all likelihood, I will shift the logic of the DBus Server starting to be in a class inheriting from QRunnable, that way I can use QThreadPool to manage the threads. Related, a topic that raised in the Buddies of Budgie standup last Saturday was the notion of using QDBus instead of sdbus-cpp. Some distributions have "too new" of a version of sdbus-cpp, as they don't have dnf in their repo possibly holding it back, so that would make including of budgie-daemon v2 more problematic. Furthermore, as I am already using QObject-based classes, QStrings, QStringList, etc. the integration with QDBus would be more natural. Neither of the things above I will tackle immediately but something I will circle back to once I get configuration out of the way. Anyways, the DBus Server was easy enough to get up and running. I already had functional code for that before I started the whole refactoring and it was already implmented as a class. Fired off all my existing getter methods for the available output heads, available mode for a given head, and the currently used mode for a head. They all worked without issue. Yay! With that out of the way, it was time to start validation of the TOML-based configuration system and more importantly, all the QtWayland::zwlr_output_configuration_head_v1 bits I switched to. I already knew the file parsing itself was going to be fine, as I literally use that pre-refactoring version on a daily basis for applying my config, just whether or not the new QtWayland bits worked is another question. Integrated that into a WaylandOrchestrator ready event callback, a separate callback from the DBus Server setup because this is exactly the cool stuff I adopted Qt6 in this specific project for. Commented out the actually applying of any configs just in case, and ran it. Unfortunately, configuration doesn't seem to work and I hit a segfault with something in the QtWayland bits. Almost certainly my code, so will need to take a look at that tomorrow, then take the lessons learned from that and apply it to all my DBus Server setters. Before ending today, I swapped over all my refresh rate code to use Hz so I am not converting it to and from MHz everywhere, and I started hooking up finished events in various places so when modes or outputs disappear I can start handling that (config bits TBD). But hey, pretty good day for development!