Light one today that was mostly spent in my own head and some pseudocode. Since I would like to start getting the daemon in the state where internally someone can just clone and run it without having to do manual work related to the config, I wanted to take some time to parse through my existing config code and figure out how I'd like to accomplish the saving / mirroring of the current output / application state (when changes are intentional) in the codebase.I have pretty much settled on keeping an internal ref to the currently matching DisplayGroup, if there is one to begin with. When there isn't, we will create one based on the state of the outputs from our WaylandOutputOrchestrator, immediately assign that as the default, and then flush the config to disk.My current line-of-thinking is we will only save to disk / modify our DisplayGroup (beside when there is no default) when a call is made over DBus. To me, that indicates a clear intent by the end user through some tooling to perform a display change. I am going to ignore changes to modes / heads / outputs otherwise since there is no telling if the end user is using some other tool that doesn't integrate with our daemon, if it's a hardware or software problem elsewhere, or they're simply plugging / unplugging hardware.If it were the case they were plugging in another display, chances are they're going to set it up so it is always in a specific position or with a specific resolution, in which case they would probably end up using our tooling.Once I end up writing the Display Configuration Batch system, then I expect to only perform the flushing to disk on successful apply (we get an event for that). Otherwise you may end up in a situation where your config is messed up and it is a manual effort to recover.Maybe there are some weird edge cases to figure out and fix, but I'll leave that to the academics and instead get more actionable feedback when it starts being put to use. So will write that out all that config code and additional bits tomorrow (it's not much really given I already have more of the serialize code as it is).After that, my goals are pretty clear IMO:
Move us off sdbus-cpp and onto QtDBus. sdbus-cpp is absolutely fantastic and I highly recommend it if you aren't integrating the Qt event loop and similar bits into your C++ application or having to contend with multiple distributions with varying varsions, so please don't take the switch as some grand endorsement of one solution over another :)
Implement Display Configuration Batch System (alongside Set Mirror and Set Position Anchor)
Shift to implementing Budgie's (WIP) global shortcuts protocol so I (and hopefully others) can start actively dogfooding Budgie on Magpie v1
Implement gamma control (mainly for night mode to be honest)