Lazily loading gtk4 symbols in order to create a dummy window seems to work. Also on gtk3. Bless be wayland subsurfaces! 🙏

Hmmm very usable yes...

Yeah I really hate client-side decorations 😡 From top to bottom: 1. Firefox is able to follow Gnome desktop settings, as it uses Gtk on the lower level 👏 2. Konsole being KDE and based on Qt is not Gtk related, just makes assumptions on what decorations should be used 3. Carla being Qt behaves the same 4. Steam does its own thing, but also assumes what decorations should be used I really thought Qt&KDE apps would behave better 😔 PS: Yes I prefer my window buttons on the left side

I mean, the app can request the compositor to have "server-side decorations" but this is treated as optional protocol. See

XDG decoration protocol | Wayland Explorer

A better way to read Wayland documentation

It is implemented on all major desktops except Gnome 😭 So now all apps need to implement their own decoration, user resizing, etc feels very backwards and wasteful. The way some compositors implement some features and some not is a bit annoying, but the main features are well supported overall. Now to get DPF to support wayland... 😁 2 / 2

After a few days writing code and running tests directly with wayland APIs... I like it! 👏 It is quite different from X11, but so is doing Windowing and events on macOS and Windows. So it is kinda like another platform altogether. The way of dealing with "protocols" feels a little weird at first, but I can really appreciate the extensibility provided and a centralized place for them. So far there is only 1 thing I hate - client-side decorations. 1/2

embedding custom wayland UI stuff on top of gtk3 and gtk4 based applications works! 🎉 the gtk APIs to get down to the wayland surface are a bit awkward, but at least its accessible. I tried the same with Qt6 and couldn't find a way to have it return the underlying wl_surface pointer. 🤷 I got an LV2 plugin UI with this setup working, but no hosts to try it out against. Modifying jalv.gtk3 is likely the easiest path... 🤔 WIP test code dump at

GitHub

GitHub - falkTX/wayland-audio-plugin-test

Contribute to falkTX/wayland-audio-plugin-test development by creating an account on GitHub.

Checking on the status of opensource audio apps and plugins (previously known to me) is quite the sad sight, quite a lot of them have been abandoned 😔 I am thinking of tagging anything that: 1. has no stable release in 10 years AND 2. has no single dev commit/change in 5 years as "abandoned". Alternatively if the project owner publicly states it is no longer maintained. The amount of projects that fit into this criteria is not small. And I feel 10 & 5 year thing is quite generous..

KXStudio June 2025 project update

KXStudio News

KXStudio Project Update (June 2025)

Hello all, it has been a while since the last project update/news....

Very short this time, writing these always takes me way too long, so I will try to go with this more formal format for the moment and see how it goes...

My big commit of the day:

GitHub

Remove dependency on asio headers · wineasio/wineasio@8d0d748

Signed-off-by: falkTX <falktx@falktx.com>

Remove ASIO dependency from WineASIO 😱 It was only a few definitions, and since the core codebase was unchanged for so long we can safely replace a few structs with API-incompatible but ABI-compatible variants. Seems to work just as before

My biggest kernel patch so far:

GitHub

Custom USB Audio setup (mmap vs virtual alsa device) · Darkglass-Electronics/radxa-kernel@cc8f13b

Signed-off-by: falkTX <falktx@falktx.com>

Changing the Linux USB audio gadget to use a very-fast mmap vs the old virtual ALSA card approach, plus also sharing 1 clock for both playback and capture (default implementation uses 1 for playback and 1 for capture, which makes them appear as separate devices - very ugly) Culmination of 1 month of work, but due to how hacky it is I will have to maintain it forever. But it's cool, gives the Darkglass Anagram unit a more unique feel!