falktx @falktx@mastodon.falktx.com

Well nevermind, fixed it in https://github.com/falkTX/wayland-audio-plugin-test/commit/ff9bdd884cfaeea95dd7402199a7741c39b7a727

(with some other little cleanup too)

basically I need to call "eglMakeCurrent(display, NULL, NULL, NULL);" to invalidate the GL context before deleting it.

everything works fine if this is the last thing the app does. crash happens if we create a new context after we delete one without "clearing" it first.

@dvzrv I think I solved the issue now, but doing some stress testing first...

seems we need to clear the GL context before destroying it. if not the next GL context creation fails badly.

Any wayland experienced developers can help out diagnose a crash in libwayland-client?

clone https://github.com/falkTX/wayland-audio-plugin-test
make && ./test-crash

(needs quite a few deps because its a test repo, should be obvious to any developer)

valgrind reports in the attached picture.

I suspect the load, unload and load again to be the issue.

@alf @dreamer yes, and related to this - I am happy that people are used DPF to create commercial plugins, it shows the viability for such things.

It is weird that they ignored LV2 though, since DPF focuses on that format first... 🤷

@alf was excited for a moment, but this doesn't seem to be open-source 😞

very meh considering the synth engine base is open...

Got gtk4 client-side window decoration size details dynamically now - https://github.com/falkTX/wayland-audio-plugin-test/blob/51b301ef46fc9d20d96716a3ce1c5589b66344cf/gtk4-host.c#L31-L62

No need for super hacky "render window offline and then fetch position based on pixels", instead it is just:
1. create dummy window
2. fetch its initial size (200x200 on my laptop)
3. add a title bar
4. get title bar size and updated window size
5. x,y offsets are (new size - old size) / 2

picture shows this working nicely, I have an intentional 20px padding around the yellow rectangle

@refi64 I went down to chromium code that calls directly into gtk and well, it's not pretty...

https://chromium.googlesource.com/chromium/src/+/lkgr/ui/gtk/window_frame_provider_gtk.cc#233

so they render an empty window "offline" to then try to find the bounds through the rendered bitmap, detecting pixels and whatnot.

this is insane, right?

@refi64 thanks, that link is helpful!

@refi64 the gtk backend seems useful yes, but also over-complicated? why is it manually drawing things when gtk has ways to render a titlebar for us?

the only thing I need right now is finding the default titlebar height and the left-shadow-position offset. there are ways to find this info without drawing everything manually right? ...right?

@ColinKinloch @refi64 it is at least nice that we mostly only need to care about gnome/gtk settings here, as everyone else implements server-side decorations.

I bet things will look super messy when testing under weston... 🤔
I mean, should KDE apps follow KDE session settings or try to follow current desktop ones? Same for Gtk based tools, they always seem to follow their own rules even on foreigner desktops. I need to try this 😅

@albertyeah I open the file? there is nothing to do for some basic highlighting.

for auto-complete and other IDE-like features Kate makes use of "LSP", plugins that talk to daemons which do the auto-complete. For C++ this would be clangd, I think its just a matter of installing it and enabling the Kate plugin.

uploaded picture is an example, it knows which fields are available in the "sum" struct.
it "just works" for cmake-based projects. for other types use "bear" to generate command list

@refi64 err, my usecase is for audio plugins, which need to be self-contained.
This means each individual binary will have to contain its own copy of the entire libdecor..? 🤦‍♂️

Also libdecor also incorrectly assumes the buttons to be always on the right side 😔

Anyhow since my target is audio plugin UIs and they are mostly going to be embed in a host view, a super minimal hack for standalone windows using gtk and subsurfaces is quite ok with me, and that one gets the buttons correct

For context: https://www.image-line.com/fl-studio-news/fl-studio-2025-whats-new-2

Never thought I would see a damn AI chatbot inside a DAW as an official feature 😕

This is not going to stop is it... 😞

Curious thing...
Font, window-title-bar and shadow size are different between gtk3 and gtk4.

This is on a stock Gnome desktop, installed today, no settings changed at all.

They look similar but have their inconsistencies.
Yay for client-side decorations! 🎉 😢

Lazily loading gtk4 symbols in order to create a dummy window seems to work.
Also on gtk3.

Bless be wayland subsurfaces! 🙏

@ggenois I didn't change anything, and there are no themes involved ? not sure why you think it's related at all to that link.

The KDE app is trying to show itself in some way that is broken outside of KDE. Typically the Qt based stuff tries to find a theme based on the current desktop/OS/etc, but here it fails badly.
The fact that the window decorations are in the wrong place leads me to think there might be some "gtk integration plugin" I am missing.

Anyhow, it just looks silly.

I tried to plug into gtk4 just for it to create a dummy window for me, idea being that then I don't need to deal with any of this lack-of-server-side-decoration business.

Well that presents its own problems, the wayland surface from the gtk4 window includes the shadow and decorations, also the size requested on start includes those too?? so I always get a smaller "window area" than expected, and I guess I now need to find that offset too somehow 🤔

Many hoops just to have window controls 😡

@bojidar_bg I did the sacrilege of running a KDE app on the Gnome desktop.

Since I am doing tests on Wayland, I need to try the Gnome desktop compositor (Mutter) to ensure things work there, as that one seems to be quite special.

I just ran dolphin, and it looks like that on a standard Debian stable.