3 ms·
I believe most plugins expose their GUI only as an X window that needs to be nested in an application window, so any change here would require reimplementing th
by heftig 3y ago
I believe most plugins expose their GUI only as an X window that needs to be nested in an application window, so any change here would require reimplementing the GUI of a lot of plugins.
But even if we do want to take this hurdle, is it even possible yet? What interfaces are available to do this on Wayland and embed a plugin-drawn GUI in a GTK 3, GTK 4, Qt 5 and/or Qt 6 application?
My guess is we still need a new spec that would probably revolve around OpenGL/EGL or Vulkan/WSI, but I'm not sure, and there's also the question of how input events are delivered.
- jabl 3y agoAFAIU Ardour itself is still using GTK 2, which has no Wayland support. You can search around on the Ardour discourse, occasionally somebody asks about the porting effort to a newer GUI toolkit, but IIRC the Ardour devs think it's too much work for little gain.
- kuon 3y agoYes, it is a complicated work, but it will have to be done eventually.
- PaulDavisThe1st 3y agoWhen do you believe that X Window API-using applications will cease to function?
- kuon 3y agoFor large x64 machine we use for music, maybe not very soon. But I work on embedded devices for medical application (basically fancy iPads with other hardware) and it's already wayland only down to the drivers. I think XWayland will be the way to go for a long time. For ardour itself, native Wayland is desirable for tooltips and other minor (but very annoying) UI things that break under XWayland, but for plugins, XWayland can be the glue.
- PaulDavisThe1st 3y agoInterestingly, Presonus are now making Studio One available on Linux, and they are "wayland native". They came up with an "interesting" solution for plugins: they just create a rendering surface and have the plugins draw on that. How this deals with event handling is unclear at this time.