Today's development was once again focused back onto budgie-daemon v2. In my Today's Dev #7, I left off with saying that my next step would be to implement a function on my output orchestrator or manager that'd create dummy head configurations to avoid protocol errors. Well, I did that, and more!The first thing I did was move my configure method out of my WaylandOutputHead class and into the WaylandOutputManager to facilitate multi-head configuration happening in one batch (this is good for the first start of the application since we'll read our config and apply any matching display group configuration wholesale).I was able to simplify the creation of my WaylandOutputConfiguration class to pass in the QtWayland::zwlr_output_configuration_v1 that I was creating in that configure function and cleaned up that class to now have:
applySelf: Dumb name that literally just calls apply() on the QtWayland::zwlr_output_configuration_v1 without any sort of conflict or recursion. Better name suggestions welcome. No applyMcApplyingface.
enable: Now takes the WaylandOutputHead so we can enable that specific head. This replaces the mistaken setHead that'd basically only allow for one head to ever exist on a config, which was simply not the correct approach.
disable: Now takes the head as well. Does what it says on the tin.
release: Another dumb name that just calls destroy(). "destroys" the config which is needed before you perform the display dispatch pending. That one took a bit to make sense the first go-around with the display configuration.
Did some further cleanup of using zwlr types as part of the constructors instead of wl_registry + id + version. Nothing particularly notable but now the constructors don't look like ass, so that makes me very happy.Okay, so things are a bit saner now. Times to make sure I carry over that sanity to the DBus Server methods, right?Started out by implementing applyNoOpConfigurationForNonSpecifiedHeads function on my WaylandOutputManager. Better names welcome, feel free to ping me on my Bluesky or Mastodon. This method takes in the WaylandOutputConfiguration we are wanting to apply head enable / disable configurations to, and a QStringList of the serials of the heads we don't want it to touch. Any serial not in that list will then enabled or disabled (no actual change is made) to avoid protocol errors. So instead of plastering 8 lines of code everywhere, it's just one function call.Went through all my existing DBus Server methods and now each one of them uses my not-terrible code (IMO):
SetCurrentMode: Attempts to set the provided output serial to the provided width, height, and refresh rate. This will find any matching mode on the head, if one doesn't exist it creates a custom mode.
SetOutputPosition: Sets the provided output serial to provided x and y coords. Surprised you on that one, right? /s
SetOutputEnabled: Sets the provided output serial to being on or off. Monitor turns on, monitor turns off. Can't explain that.
There will be more but that is something I will circle back to...well once everything else works again.Lastly, I updated the display configuration (like literally the logic for apply the config file for the displays) to use all the new C++ classes and methods. Trust me, it's way cooler than it sounds. The code looks great now.Tried to compile and still getting those damn linker issues. I think I might prod some gems in the KDE community about it tomorrow to see if they can spot any stupidity being done on my part. Once I can get it compiled and linking, I'm going to move on to debug printing what my WaylandOrchestrator thinks is my output state. Once that's all validated I'll hook it up via Qt's signal / slot fanciness to apply the configuration. Then we'll be back to square one before all the refactoring and Qt6-ifying.That's it for today! Happy Friday!