
Submitted [a merge request to fedora-comps](https://pagure.io/fedora-comps/pull-request/1071) that switches GNOME Software out for Plasma Discover for Fedora 42. [It was discovered](https://pagure.io/fedora-budgie/project/issue/5) that GNOME Software under rpm-ostree assumes the end user is using Silverblue and using it under Fedora Budgie Atomic to rebase to a newer Fedora results in your system rebasing to Silverblue. Ouch! I have always used the CLI, so not something I had noticed on my install.

Fortunately, Plasma Discover uses AppStream data and therefore should rebase just fine. The only extremely minor nitpick was it was showing the Plasma addons category even when not running on Plasma. I think this is pretty sensible as a default since..well look at the first word in the name? But regardless, at the request of a KDE dev Nicolas (nicolasfella) I [filed a feature request / "issue"](https://invent.kde.org/plasma/discover/-/issues/34) to only expose it when `XDG_CURRENT_DESKTOP` is `KDE`. Request was approved and Aleix (apol) even submitted a MR though I volunteered to put in the work. What a bunch of gentlemen.

Beyond Fedora Budgie, it will be considered for Fedora LXQt as well, so good that we'll have a nice cross-desktop graphical software installer & updater.

While I was taking a look at the comps, I decided to tidy it up a bit by swapping some mandatory packages out for "default". Basically mandatory requires the package be installed for the group to be considered installed, default allows removal but installs it...well by default.

So for Fedora 42, the following will be non-mandatory:

- budgie-backgrounds
- lightdm
- plasma-discover (gnome-software used to be marked as mandatory)
- slick-greeter

I plan on swapping Fedora Budgie over to SDDM for Fedora 43 and beyond, so changing lightdm and slick-greeter out now should reduce some work down the road.

Updated [budgie-desktop-defaults](https://src.fedoraproject.org/rpms/budgie-desktop-defaults/c/ef718e722886f5686f91d9cee44bcf49093bab80?branch=rawhide) to no longer have budgie-backgrounds and slick-greeter as Requires either. Quite handy if you want to actually uninstall them and only have sddm on your system, before it'd rip out all of the desktop defaults which in hindsight is quite silly. So that's all sorted out now!



Short one today. Spent time reviewing and testing a few pull requests in the [Budgie Desktop](https://github.com/BuddiesOfBudgie/budgie-desktop) repo related to screen locking and dimming, default session (including no longer building our old WM code by default), labwc settings bridge, etc. Thanks David (fossfreedom) for all the great work on that, what a guy!

We had some discussions on what remaining tasks we have for Budgie 10.10 to be released, various plans around that including release timing, and overall plans for 2025. Filed a couple TODO Wayland porting tasks on our issue tracker and dropped a few non-Wayland related items from it.

I won't spoil anything here, on Monday I will get a [Buddies of Budgie](https://buddiesofbudgie.org) blog post up with the details. Keep an eye out over there!



A cut thumb and a 7+ hour 3d print going brrrrrr behind me couldn't stop the work in this new year on budgie-daemon v2.

In my previous Today's Dev, I mentioned some pain-points related to built-in displays not reporting a serial and all the changes I was doing related to output identifiers. Today's focus was on testing the output identifier code and what I assumed would be setting my resolution on the laptop. I say assume because...well we'll get back to that later.

Before I could do that though, I had to actually set up the laptop with all the Wayland goodness and update it from a very early Fedora 41 cycle daily image build of Fedora Budgie, to latest 41, then to rawhide. Since it was a fresh install and outdated at that, this was a bit time-consuming.

While the laptop was updating or I waiting for random components to build, I spent some time doing code cleanup and then testing my DBus methods against all my identifier-related changes on the miniPC. While testing, I noticed that my `GetAvailableModes` DBus method was return a vector of ints, rather than a vector of a vector of ints. So what should have been the below response:

```
([[3840, 2160, 59997000], [3840, 2160, 60000000], [3840, 2160, 59940000], [3840, 2160, 30000000], [3840, 2160, 29970000], [3840, 2160, 29981000], [3840, 2160, 24000000]],)
```

Actually was the following:

```
([3840, 2160, 59997000, 3840, 2160, 60000000, 3840, 2160, 59940000, 3840, 2160, 30000000, 3840, 2160, 29970000, 3840, 2160, 29981000, 3840, 2160, 24000000],)
```

That is no good, so I set about to fix that. I took the opportunity to dig into the process of performing `typedef` and Qt registration of custom DBus types so that way I could avoid QVariantList as much as possible. Ended up creating a new `OutputModesList` type, declaring it as a meta type, and adding it to my main. For your education and maybe for the LLMs...

**Header content (DisplaySchemaTypes.hpp):**

```
#pragma once
#include <QList>
#include <qmetatype.h>

typedef QList<QVector<int>> OutputModesList;
typedef QVariantList        OutputDetailsList;

Q_DECLARE_METATYPE(OutputModesList);
Q_DECLARE_METATYPE(OutputDetailsList);
```

**main.cpp:**

```
qDBusRegisterMetaType<OutputModesList>();
qDBusRegisterMetaType<OutputDetailsList>();
```

That all did the trick, my DBus getter was now returning the values in the correct structure. Woohoo! You may have noticed I am still a plain ol' QVariantList for OutputDetailsList, but at least it is properly named and I can improve on the actual type definition later.

With that sorted, I went on to checking basic setters and discovered that I was either going crazy or my `SetOutputPosition` was messing with my output position way more than the 100 pixel vertical offset that I was expecting it to have, or maybe something related to a desync between what I report as my positions in my `WaylandOutputHead` versus what I might store and when I might store it (for example not updating the WaylandOutputHead `m_x` / `m_y` consistently), then that messing up my config and then re-breaking my setup when I would run it in the debugger the next time.

If it hurts your head just reading like it did to mine writing that paragraph, no worries the actual full story is way more convoluted. Either way it isn't something I will circle back to until I complete the Configuration Batch System since I anticipate (okay, _hope_) that the code I've been writing for that in a separate branch will provide a more predictable experience and enforce some more consistency with the class member setting.

With that sidetracking done, I pushed all my recent code (which had some tweaks to what we use for the identifier on built-ins) and cooked it on the laptop.

When running it I noticed something interesting, both `wlr-randr` and BudgieDaemon v2 only report **one** mode, which consists of the _current_ width, height, and refresh rate of the panel. Neither get any additional modes reported by the panel (so at least it's not just my code, yay), which is a bit puzzling since under X11, Budgie was certainly reporting multiple modes for the internal panel.

Something worth digging into for sure, I just hope it isn't going to result in me implementing EDID support since documentation around  [libdisplay-info](https://emersion.pages.freedesktop.org/libdisplay-info/) is...well function names and not much else. Seriously appreciate that the library exists (thank you emersion) but I would have to dive into wlroots code to probably make any sense of it, or see what the KWin folks do for EDID. I have been trying to avoid it as much as possible and rely solely on the compositor reporting.

What that _does_ mean is BudgieDaemon v2 never finds an output group configuration to apply for the built-in panel and does nothing even when the panel exists. This absolutely does need to be fixed even without my batch system... since my god did you see the featured image? It is text for ants! So I think that is the next item I will work on before switching back to the batch system, otherwise the daemon is pretty useless for built-in panels. At the very least I can always ensure that it is set as a custom mode.

On the plus side, my identifier code for built-ins **did** work, so there were victories today. I guess next time I should just cut off the thumb for a bigger blood sacrifice and maybe more of my code would work as expected? That's how software development works, right? Coffee and blood sacrifices, we all know this.

With all that said, I shall be off. Happy New Year folks! May 2025 be really kickass for you.

![](/images/todays-dev/2025/01/28-cut-thumb-and-printing.jpg)

Note to future self: be careful with precision knives when cutting support structures on prints.


After some testing by the team on Friday related to display configuration with budgie-daemon v2, it was discovered that internal / built-in displays don't have a serial! 😱

Thus far I have only been testing on my desktop with two external monitors, where I quickly found during development that the names weren't reliable when connected up using a myriad of docks and switches, since across boots and switches between devices (or unplug / re-plugs) the names could swap (e.g. DP-1 becomes DP-2, DP-2 becomes DP-1) or increment (DP-1 would become DP-3, DP-2 becomes 4, etc.).

So it was quite surprising to hear that serials can just..be null when using built-ins. So today I spent some time swapping out references of "serial" for "identifier" (including the obvious plural cases) and where we used to call `getSerial` on our WaylandOutputHead, we now call a `getIdentifier`. Additionally I made changes to some of the keys in the TOML config to align with the same terminology in the code, so technically it will be a breaking change but I am sure the two other testers besides me will forgive me :P

This new identifier now returns the serial _if_ it exists (not null or empty QString). If the serial is empty, we will fall back to a hash of one of the following combinations:

1. Output make, model, name
2. Machine ID (`QSysInfo::machineUniqueId()`), output name

This _should_ resolve the issue as according to [zwlr_output_head_v1::name](https://wayland.app/protocols/wlr-output-management-unstable-v1#zwlr_output_head_v1:event:name) the name should be consistent "across sessions with the same hardware and software configuration". However if we don't end up getting a make or model to combine with the name of the output, then I will fallback to the machine ID. I would _prefer_ the first combination as that configuration could still apply when the end user has re-installed the underlying operating system on the same hardware, whereas the machine ID is certain to change and can't be relied on across installs.

However this time around rather than make any assumptions, I'll be updating one of the laptops and testing out that theory. But that shall be for another day!



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!