Today was a mish-mash of a day in terms of development. Started out the morning by fixing a small bug in a change 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, 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, 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 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!