Today was a pretty productive day when it came to budgie-daemon v2. I started out the morning by implementing the updating of our active DisplayGroup (config bits) in the DBus setters, e.g. calling the DBus Setter for SetPosition will update the position for that output in the group, then flush the updated serialized config to disk. After that, I took on the work of moving the daemon from sdbus-cpp to QtDBus, enabling me to take advantage of native Qt types like QString. I started out by taking a look at qdbusxml2cpp-qt6 for generating the adaptors based on my XML schema. I had to mark up my XML schema with annotations, which either aren't documented or I'm blind, so ended up using a couple LLMs for that. Gemini kept messing up on my GetAvailableModes method which returns an array (a) of width (i), height (i), and width (i) -- together declared as a(iii). The annotation value is QList<QList<int>> and not QList<QList<int>> which Gemini kept asserting was correct, Claude got it right though and it was very much a "today I learned" on the encoding there. Once the annotations were sorted, the DisplaysAdaptor generated without issue. I took the opportunity to rename stuff from generic server to DisplayService, since in reality we will have multiple adaptors for different interfaces, before starting work on refactoring my existing sdbus-cpp display code to be a class that has the ref to the generated adaptor (as opposed to inheritance). I tried the inheritance route but it kept exposing both the adaptor Object path (/org/buddiesofbudgie/BudgieDaemonX/Displays) as well as an internal Object path that was something like local.budgiedaemonv2.buddiesofbudgie.org.bd.DisplayService. I didn't want to start overriding the adaptor by specifying in my class Q_CLASSINFO("D-Bus Interface", "org.buddiesofbudgie.BudgieDaemonX.Displays") since I figured that was very much not the way to go about it, and ended up settling on my DisplayService class inheriting from QObject itself and then creating the DisplaysAdaptor during construction. Porting over the code to the class methods was trivial and frankly not worth talking about. Once that was sorted I updated my main.cpp to register the object and service once the WaylandOrchestator::ready signal was emitted. Everything seems to work just as well as when I was using sdbus-cpp, and memory usage seems to be basically identical as well. Quite happy with the result! Next up will be working on the Display Configuration Batch system, which I expect to be a longer running task.