
Managed to fix the bug with `GetAvailableModes` not working. Went back in time and noticed that it was basically broken ever I had completed the port to QDBus, "polished" it up after testing, and committing that changed code. I had decided to try to be clever by specifying the result of the getter as a `QList<QList<int>>` and it seems that, for whatever reason, QDBus really didn't like that. It doesn't say it doesn't like that, instead it just happily does the codegen similar to my problems with multiple returns on GetCurrentOutputDetails and then leaves it up to you to figure out why. If it was a human, I would say it had a "shit-eating grin" as it willfully performed its duties knowing I would fail.

Switching both to use QVariantList [does the trick](https://github.com/BuddiesOfBudgie/budgie-daemon-v2/commit/a7a39089bdcad6d839abbb864a927bfeb9553989). If you have better ideas, feel free to reach out. Until then, I am happily returning to the saga that is the Display Configuration Batch system.


Short one today. Just spent some time trying to dig into why the GetAvailableModes D-Bus method isn't working:

```
[warning] QDBusConnection: couldn't handle call to GetAvailableModes, no slot matched
[warning] QDBusConnection: couldn't handle call to GetAvailableModes, no slot matched
[warning] Could not find slot DisplaysAdaptor::GetAvailableModes
```

Pretty strange seeing as the slot _does_ exist:

```
public Q_SLOTS: // METHODS
    QList<QList<int>> GetAvailableModes(const QString &serial);
    QStringList GetAvailableOutputs();
    QVariantList GetCurrentOutputDetails(const QString &serial);
    void SetCurrentMode(const QString &serial, int width, int height, double refresh, bool preferred);
    void SetOutputEnabled(const QString &serial, bool enabled);
    void SetOutputPosition(const QString &serial, int x, int y);
```

Okay so what about in the client code?

```
QList<QList<int>> DisplaysAdaptor::GetAvailableModes(const QString& serial) {
  // handle method call org.buddiesofbudgie.BudgieDaemonX.Displays.GetAvailableModes
  QList<QList<int>> modes;
  QMetaObject::invokeMethod(parent(), "GetAvailableModes", Q_RETURN_ARG(QList<QList<int>>, modes), Q_ARG(QString, serial));
  return modes;
}
```

Yea okay so it's defined there too 🤔

Tried stashing all of my changes, still didn't work, so at least I know it's nothing in my current changes. Tried adding a qInfo to the DisplaysAdaptor method for it, never gets that far. Don't have the energy to dig deeper today, tomorrow I will see about going back further to see when it all borked.


Today was a mish-mash of a day in terms of development.

Started out the morning by [fixing a small bug](https://github.com/BuddiesOfBudgie/budgie-desktop/commit/a4aae3774f247ed4a046617fa27feb3b07370efb) in a [change](https://github.com/BuddiesOfBudgie/budgie-desktop/commit/8a25ad41a6f6dab205fe9d59150d7302597249b4) from Evan yesterday night that fixed up window grouping in our IconTasklist. Thanks to his contribution on that front, windows now group properly again on top of pinned apps (e.g. if you had pinned Firefox, it wouldn't group on that pinned app but rather on the first instance of it running, which would spawn a second IconButton). My small fix just changed us from getting a GIcon to a GdkPixbuf from the libxfce4windowing.Application, with the reason being the gicon would either made the icon completely white or black (depending on if the app was minimized or not), rather than the dimmed style we have with the pixbufs.

After my eyes were no longer triggered by bright icons in my panel, I decided to [port Budgie Desktop View over to Wayland](https://github.com/BuddiesOfBudgie/budgie-desktop-view/commit/6585841a3269dc84b28adab8f5e3963290e5521f), leveraging libxfce4windowing and GtkLayerShell similar to our porting work in the budgie-desktop repo itself. It now goes onto the background layer, anchors to top left, and doesn't demand keyboard input. Previously it'd look like any other window, including with window decorations (server side decorations), which obviously looked silly. Now that's one less thing we have to think about for the porting effort.

After that, I dug into autostart of `org.buddiesofbudgie.BudgieDaemonV2`. First tried with an autostarting desktop file, but since our session management is a bit wonky at the moment that didn't work out. Tried with a systemd unit after that but unfortunately the compositor isn't fully up by the time systemd tries to trigger the user service, so as a result it never ends up starting. Eventually, I settled on the (hopefully temporary) solution of using `labwc` autostart and shoving that into `/etc/xdg/labwc`. It won't be great if there happens to be another one there, but that'd mean the end user has gone out of their way to create it in the system-wide path and not their `.config/labwc` path. It'll work for now but I would ideally like to see labwc have a systemd unit that can be set as a requires, and for our own Magpie compositor we'd do the same.

With that [sorted](https://github.com/BuddiesOfBudgie/budgie-daemon-v2/commit/a051f96f1afaf447195463dc84a00e7bfb754160), I turned a bit to working on fixing up the Workspace Switcher. We had ported it to libxfce4windowing a long time ago but had not yet circled back around to nuking all the instances where we were calling to get the xid (those don't exist under Wayland, you just have class names). Worked on that for a while before then having to turn my attention back to budgie-daemon v2. Will still need to wrap that up but uncovered a rats nest related to window geometry fetching calls that don't work under Wayland, so that's going to be real "fun" to sort out.

Evan started using Budgie Desktop under labwc yesterday, so there was a bit of onboarding to be done during the standup and today some helping out on some pain-points he was having with display configuration. How conveniently I have been living in that world for a while now!

Apparently the `GetCurrentOutputDetails` DBus method got busted when I ported it from sdbus-cpp to QtDBus. It turns out that qdbusxml2cpp will generate an empty method body in the adaptor when you have a DBus method that returns more than one argument. So there wasn't a compiler error, it just...didn't do anything because the method would never call the parent's handler of the D-Bus method. I came across a [bug report from 2017](https://bugreports.qt.io/browse/QTBUG-61371) on this where the solution indicated was to use `-l` to specify the class name to redirect to. Personally would have preferred the tool actually yell at me that this was going to be a problem rather than silently generating code that makes it seem like everything would "just work", I could have fixed it back _during_ the port rather than being surprised by it now. Oh well.

I spent a while trying to mess around with that however because of how I have everything namespaced and split out, it was proving to be a real pain. Until I come up with some better idea or circle back around to un-namespacing all that display code, I instead just changed `GetCurrentOutputDetails` to be an output of a `QVariantList`, which _does_ mean all the result content is now stuff into an array, but hey it works. Not a fan though.

While I was faffing around with all of that, I discovered that if I was in my `src/dbus` directory when I performed the qdbusxml2cpp call, it didn't mess up the include for the generated header in the generated client-code, so a quick fix to my Taskfile to specify `dir: src/dbus` did the trick and I don't have to unmangle it by hand anymore.

Got `GetCurrentOutputDetails` working but managed to break the `GetAvailableModes` DBus method now, yay /s

So will do some bug squashing tomorrow then get back to work on the display configuration batch system. Today's mix of tasks was a nice break from the usual!


Today I continued work on budgie-daemon v2's Display Configuration Batch system. I cleaned up my DisplayConfigurationBatchSystem to no longer hold references to each output serial's Batch class, rather I have that in the DisplayConfigurationCalculation. Another key change I made was no longer having the system scrap the calculation and make a new one, rather I have it call a reset function that clears out some of the various computed properties of the calculation class, and I also have one calculation (rather than it being an `std::optional`). Hooked up a new outputRemoved slot on the batch system to WaylandOutputManager, so we can now call the calculation reset if an output is removed while the user is configuring heads.

The `calculate` method of DisplayConfigurationCalculation is looking much nicer as well. Since we have references to all the Batch class instances with their actions, I am able to iterate over each of the batches, cherry-pick the actions (which are now in a QMap of the action type to the action itself) when creating the QRect for the output properties, have it fallback to the WaylandOutputManager if we don't have a SetMode action (so basically "keep it the same as what is is now" for width / height / refresh), etc.

Still need to write a lot of the trickier bits of the method, but good progress made on it today and I'm much happier with _this_ version of the implementation than my previous ideas.



As detailed in [yesterday's Today's Dev](/todays-dev/21), plan for today was to work on the Display Configuration Batch system. Started working out the logic for the `DisplayConfigurationCalculation::calculate` and very quickly realized that there was some streamlining to do on how I store actions. Mulled over that for a while, did some dishes and cooking to let my brain do its own background cookin on some ideas. Came to the conclusion that instead of a QList of actions, I'll have a map of the _type_ of action to the action itself stored on the batch, since you can't have several of a specific type anyways.

It should also greatly simplify generating the QRects for each of the outputs since I need to know both any available SetMode action as well as any Transform action to know basically what should be the width and height (will vary based on the transform if any). To do it during the calculation would require a bunch of action iteration or storing the actions temporarily in a manner that would basically be a QMap anyways.

So plan is to continue hacking on the calculation logic tomorrow, will be interesting to see how close or far to my initial idea for the system the end result is.

But for now, off to prep for the release of the early access of Path of Exile 2!


Today was entirely focused on continuing to polish the definition work on the Display Configuration Batch system. Carved out the definition for the batch actions, cleaned up some extraneous class definitions for Enabling / Disabling Batch classes, and did an initial pass at the DisplayConfigurationCalculation class definition.

Right now my current line of thinking is reflected in the following breakdown:

You have _one_ `DisplayConfigurationBatchSystem`. It is expected that the applications which would integrate this batch system (for example Budgie Control Center) would use a D-Bus method to perform a reset of the system when loading the view that'd show displays. Maybe there could be other ways of clearing it like if you were to suspend your system or something, but I am not too worried about automatically clearing it at this time.

This class would hold a `QMap` of our output serials to `DisplayConfigurationBatch` classes, so there would be at most one for each output serial. Adding a batch for the same serial would clear out any existing one. It would also hold a reference to a `DisplayConfigurationCalculation`, assuming that either `apply` or `test` are called to call our internal `createCalculation` function on the batch system.

This calculation class would be responsible for...well the calculation obviously. It would aggregate all batch system actions, filter out duplicate ones that would have added earliest (for example setting an anchor, then changing it later, this would filter out the first one), calculate the global space and positions for each output, etc.

To accomplish this, our DisplayConfigurationBatch createCalculate would call the `DisplayConfigurationCalculation::addAction`, then at the end call its `calculate` function. `addAction` would add it to a QList of buffered actions. `calculate` would process these and add them to a new QList just called `m_actions`.

Doing some investigating work today, I came across [QRect](https://doc.qt.io/qt-6/qrect.html) and [QSize](https://doc.qt.io/qt-6/qsize.html). QRect seems pretty dope: it enables us to define coordinates (x, y), dimensions (width, height), and keeps it all in a nice container that we could use during our calculation to determine and avoid intersections (it has functions like `intersected` and `intersects`). For rotation, I could basically just call `transpose` to swap width and height (e.g. 90deg or -90deg rotations). I could use several `united` calls to get the bounding rectangle between two, which would be handy for iterating over output rects to get the global space (total height and width of all the outputs, with proper handling of mirrored outputs).

All extremely handy stuff, so my current thinking is having a QRect of the global space, then a QMap of each output to their own QRect.

For `DisplayConfigurationBatch`, you create it for a specific serial with one of two types: `DisplayConfigurationBatchType::Enable` or `DisplayConfigurationBatchType::Disable`. If you set it to `Enable`, you will be allowed to add actions.

`DisplayConfigurationBatchAction` contains basically all the possible properties (as members) for every possible type of an action. Maybe not the best way to do it but it can be cleaned up later after I get some feedback on it.

Current types are:

- SetGamma
- SetMirrorOf
- SetMode
- SetPositionAnchor
- SetScale
- SetTransform

Each of these map to a different constructor, all taking the relevant args for their given type. I won't get into all of them...because why...but here are a couple examples:

```
DisplayConfigurationBatchAction mode(QSize *dimensions, int refresh, QObject *parent = nullptr);
DisplayConfigurationBatchAction setPositionAnchor(
  QString *serial,
  DisplayConfigurationHorizontalAnchor horizontal,
  DisplayConfigurationVerticalAnchor vertical,
  QObject *parent = nullptr
);
```

In the first one, you might see that I am using QSize instead of specifying width and height separately. Not sure that'll stick around but figured I'd change things up a bit.

For setPositionAnchor, it takes a couple different anchor types (one for horizontal and another for vertical).

I already described anchoring in a previous Today's Dev, but to here are the current literal enum values:

```
enum DisplayConfigurationVerticalAnchor {
    Above,
    Top,
    Middle,
    Bottom,
    Below
};

enum DisplayConfigurationHorizontalAnchor {
    Left,
    Right,
    Center,
};
```

So yea, sorted out all the definitions. Bit of thinking involved I'd say. Started working on implementing some of the actual methods, starting with `DisplayConfigurationBatchSystem` but a lot of it is placeholder / TODOs until I carve more of the methods out.

And guess what I'll be working on tomorrow? :)


Speedrunning this one today. Skipped yesterday since it was my birthday.

I switched out calls to `std::cout` and `std::cerr` with [Qt logging functions](https://doc.qt.io/qt-6/qtlogging.html).

Fired off an email to the amazing folks at [Jetbrains](https://jetbrains.com) as Buddies of Budgie is in their open source program. As part of being in that program, Jetbrains generously provides licenses that the organization can use for their software such as [CLion](https://www.jetbrains.com/clion/) and [RustRover](https://www.jetbrains.com/rust/). These licenses last a year at a time and it only takes an email or two towards the end of the licenses to request for it to be extended. While I'm at it, I always mention _how_ the team is leveraging their products. As a couple examples, Campbell (serebit) has been using CLion for Magpie v1 (Budgie's C++ Wayland compositor leveraging wlroots) and RustRover for [Magothy](https://codeberg.org/serebit/magothy) (hardware profiling tool). I have been using CLion for budgie-daemon v2 and [Koto's Qt6 port](https://github.com/JoshStrobl/koto/tree/qt6). In my experience, CLion has been damn near flawless for C++ development where many others would struggle (whether that be with highlighting, LSP, linting, the debugger tooling), especially with Koto.

If you lead an open source community and think Jetbrains tooling would be useful for you, I'd encourage you to check out their [Open Source support](https://www.jetbrains.com/community/opensource/) page. Not an ad here, I just don't want you to waste time fucking with tooling, spend it on being productive instead.

Started working on the Display Configuration Batch system (_can I just call it DCB from now on?_), almost entirely around the class definitions currently. Trying to get a feel of how it'll look at an abstract definition level before writing the actual code. Nothing to show for it yet.

That's it for today. Maybe lost the speedrun. Not sorry.


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](https://github.com/Kistler-Group/sdbus-cpp/blob/master/docs/using-sdbus-c++.md) to [QtDBus](https://doc.qt.io/qt-6/qtdbus-index.html), 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&lt;QList&lt;int&gt;&gt;` 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.


Today was a good day for all the config code in budgie-daemon v2. In [yesterday's Today's Dev](/todays-dev/17), I discussed my plans for changing up a fair bit of this code to ensure that when we do not have a config or a matching group, we generate a new "active group" and make sure that gets flushed to disk (with the intent to not overwrite any other groups in the config of course).

Excluding the code for updating the active DisplayGroup when performing DBus setter method calls, everything works and the config basically mirrors my hand-written TOML config.

To accomplish it, I first set out to change the DisplayConfig, DisplayGrouping, and DisplayGroupOutputConfig structs into classes, with respective private or protected members and appropriate setters and getters (to ensure more predictable behavior that messing with the struct members directly). I no longer have utils for generating those structs from TOML values, but rather have class constructors that take in the `const toml::value&` and a method `toToml` for converting the class back into a `toml::ordered_value`. This helped with tidying up the config code in general. While I was at it, I moved them to using QString, QList, and QStringList types for various members.

In our `DisplayGroup`, we now have a method that is called when we have no matching DisplayGroup for the current Wayland output management / heads state, `createDisplayGroupForState`. This method:

1. Creates a new `DisplayGroup`
2. Sets the name to an auto-generated name that is basically a comma-separated list of the output serials, then appended with `(Auto Generated)`. For example: `0x32394658, 0x41505846 (Auto Generated)`
3. Sets the output serials to a `QStringList` of all of our head serials from the manager.
4. Sets it as the preferred group
5. Sets the primary output to the first output. This will almost certainly change in the future.

After this, it'll generate the DisplayGroupOutputConfig for each of the outputs and add those to the DisplayGroup.

With this created group from the state, we set it as the active group then immediately call our new `saveState` which will create a config (or simply add to it if we already had one but no matched group) and write it to disk. I won't go into the implementation detail for that stuff, feel free to [check the commit](https://github.com/BuddiesOfBudgie/budgie-daemon-v2/commit/3635d0b64f3199057dcfa5b7167025c662fd4e61) if you are interested. Instead, I'd rather just show you the config it generates 😀

```
[preferences]
automatic_attach_outputs_relative_position = "none"

[[group]]
name = "0x32394658, 0x41505846 (Auto Generated)"
preferred = true
output_serials = ["0x32394658", "0x41505846"]
primary_output = "0x32394658"

[[group.output]]
serial = "0x32394658"
width = 3840
height = 2160
refresh = 60000000
position = [0, 0]
scale = 1.0
rotation = 0
adaptive_sync = false
disabled = false

[[group.output]]
serial = "0x41505846"
width = 3840
height = 2160
refresh = 60000000
position = [3840, 0]
scale = 1.0
rotation = 0
adaptive_sync = false
disabled = false
```

There still some work I _may_ need to do related to the positioning code, since it is defining the position for `0x41505846` as `3840` on `x` when in reality it is `0x32394658`, but I am doubtful a "normal" user would get impacted by that since they have never exactly been using an old implementation of `budgie-daemon v2` with an existing config before, and in all likelihood the positions would be correct on first boot without the config, and if they are not then that is something the user would fix via display configuration...and therefore the correct state would get dumped to the config. So I might be overthinking that issue.

Either way, good progress on that today. Tomorrow I'll work on ensuring the active DisplayGroup state is updated when changes are performed over DBus, then crack on with the goals listed in yesterday's post.


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:

1. 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 :)
2. Implement Display Configuration Batch System (alongside Set Mirror and Set Position Anchor)
3. Shift to implementing Budgie's (WIP) global shortcuts protocol so I (and hopefully others) can start actively dogfooding Budgie on Magpie v1
4. Implement gamma control (mainly for night mode to be honest)

Happy Friday all!


In [yesterday's Today's Dev](/todays-dev/15), I got configuration applying working again as well as functional setters for my DBus Server. Today, I planned on starting to mind-map a solution for a configuration change batching system.

Massive image below, I would suggest opening in a new tab and zooming in.

![](/images/todays-dev/2024/11/bd-lab-config-batch-system.png)

My _current_ line of thinking (almost certainly subject to change as I work on this) is that it all centers around a singular WaylandOutputConfigurationBatch. You create new events starting with enabling or disabling an output, which is no different than currently. If you are enabling / keeping an output enabled, you will have available the following events:

- Set Gamma: This would use [wlr-gamma-control-unstable](https://wayland.app/protocols/wlr-gamma-control-unstable-v1) for creating per-output gamma controls.
- Set Mirror Of: This event would enable you to set the specified "child" output as a mirror of a "parent" one. In reality, the way you accomplish this is just by having one output in the same coordinate space as another so they overlap.
- Set Mode: Set the resolution & refresh rate mode.
- Set Position: Probably keep this for now but plan to deprecate.
- Set Position Anchor: This event would facilitate positioning a given output (child) relative to another (parent), with horizontal and vertical anchoring. I would prefer this to replace the Set Position event already, though realistically I think both will stick around for a bit so others on the team can tinker, even though that'll make "positioning" fun. Calculating the change and end position of an output should be much simpler when it is explicitly anchoring another.
- Set Scale: Pretty self-explanatory on this one?
- Set Transform: Varying degrees of valid rotation. Uses `wl_output::transform` so there are specific values. [Doc here](https://wayland.app/protocols/wayland#wl_output:enum:transform) if you are interested.

I would expect that the change calculation would:

1. Process each output's gamma, mode, and scale events. We would make the respective zwlr output configuration head call and also calculate on our own the end-result resolution based on mode selected and scale.
2. Aggregate all position anchoring events. Calculate the total global coordinate space used by all the outputs. This will be based on the total resolution of all the chosen / current modes * scale factors - mirror events (eliminate this mode from coordinate calculation). From then, create a tree of parent to children, find left most output, calculate offsets based on that monitor.
3/ Create position calls for those heads, for those in mirror set it to coordinate space of related monitor.

Perform test or apply. If you were to test first, we would probably do some sort of result saving, so that way we don't need to re-perform the calculation on apply. If there is any event before apply, we would invalidate the result and just re-calculate on apply as if you never performed a test, assuming you don't test again. In which case around and around we gooooooo.

So that's where my head is at. Ping me on my Bluesky or Mastodon (shown below) if you have any better ideas, I'd love to hear them.


In [yesterday's Today's Dev](/todays-dev/14), I got most of the TOML-based configuration bits working against excluding the actual applying due to a segfault when trying to use the `QtWayland::zwlr_output_configuration_head_v1` returned from the configuration Object after enabling a given head (output / display). I also got the D-Bus server running again with getters returning expected data.

Today, I implemented a new `WaylandOutputConfigurationHead` class that inherits from the QtWayland one referenced above, with some camelCased methods that map to the respective method in the inherited class (e.g. `setPosition` -> `set_position`). Fixed up some `wl_display_dispatch_pending` calls for the non-pending named function and got configuration applying to work again! 🎉 Big deal after all the refactoring and work I have done.

Fired up D-Feet and started testing out my setter methods. I have validated that the following work, with some tinkering certainly needed:

1. `SetCurrentMode` - Setting the mode of an output to a different one works. I was able to change the resolution of my left-side monitor to 2560x1440. I then promptly changed it back because oh my god compared to 4k, 1440p feels so small!
2. `SetOutputPosition` - Tested changing the Y position of my left-hand monitor. It worked. Not really much to say about that one.
3. `SetOutputEnabled` - This worked when turning the monitor off but my reference to wl_registry kinda exploded for some reason when trying to turn the monitor back on, so not sure about that one yet. Could be a problem in the daemon or in the compositor. Might have to test on Magpie v1 (as opposed to current testing with labwc) to learn more.

Now that I got all of that working, I intend on starting mind-mapping a solution (using the [Excalidraw plugin](https://github.com/zsviczian/obsidian-excalidraw-plugin) within [Obsidian](https://obsidian.md/) -- highly recommend both by the way) for a configuration change batching system. There is almost certainly a better name for it, it's by no means a new idea. Effectively all my current DBus setters like setting mode, position relative to another head, etc. are all individual calls. I would like to change it so configuration changes are layered on top of each other, then firing off a "test" or "apply" event would condense all those events down (eliminating any extraneous events) into one WaylandOutputConfiguration with the changes necessary for each head.

To describe it to a "Josh before his morning coffee", I want you to imagine your typical display configuration graphical software. You have rectangles, typically with labels in them describing the displays. At first, this is based off the current state of those heads (their position, resolution, refresh rate, adaptive sync, enabled / disabled, etc.). If you want to change the resolution and position of your monitors all in one go, you'd probably set their resolution so the rectangles change size, then move them around, then click apply. You're not changing the resolution, clicking apply, moving one monitor, clicking apply, moving another monitor, clicking apply. Oh god now you've gone insane, you're closing out of the software and making a strongly worded social media post.

To make it more sane, I would want it so you'd break it down by changes to each head, request a new instance for batch configuration, send all of those over the wire, then apply it all at once. Creating a new instance would invalidate any existing one. I'm already doing something sorta similar with my config applying, I just have the luxury of being able to pre-define all my necessary config calls like setPosition ahead-of-time because I have the config. So I would expect to transform that into using the batch config system before moving on to my DBus changes (including probably the move to QtDBus).

So to the literal drawing board I shall go tomorrow!


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](https://doc.qt.io/qt-6/threads-technologies.html) 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!



In [Today's Dev #10](/todays-dev/10), I ended the post by mentioning that I was still getting the linker issues in the QtWayland code having undefined references to the related generated C client code and header. Keep in mind, this was also something that my friend Neal and I looked at for several hours on Today's Dev #3 as well.

Well I asked in the KDE KWin Matrix room (since they seem to be the most in-depth example of QtWayland and the KDE folks are always super cool and helpful) and asked if anyone could help a guy out. [David](https://blog.david-redondo.de/) and [Xaver](https://zamundaaa.github.io/) were kind enough to jump in and take a look at my budgie-daemon v2 code. After some back and forth, David stripped the project down to literally just a `main.cpp` file and directly added the generated qtwaylandscanner sources.

That is when he noticed that it wasn't including the C/H files at all! Yea, that'd do it. Kinda hard to have a reference to functions if the files aren't being added. But why?

My CMakeLists.txt project definition specified `LANGUAGES CXX` which means it will only accept files of that given type. It does **not** warn about files it will not include. I was under the impression it'd be leveraged for checking if the tooling required for CXX was available (e.g. clang++ or g++). Nope. Not at all. But hey, today several of us learned! Removing that languages restriction did the trick!

**Finally** got it to compiling, noticed no events were coming in, fixed my `WaylandOutputManager` not actually setting the properties of `QtWayland::zwlr_output_manager_v1`, re-added the necessary `wl_` calls for dispatch and roundtrip, and started successfully getting events including a new `WaylandOutputHead`.

Just need to start fixing these segfaults! Hopefully won't be as painful as the linker shenanigans, right? 😄

This is what I would call a "failed successfully". This different kind of failure is one I seriously welcome. Massive thank you to David and Xaver for their help 👏