Since GIMP made the jump to GTK3 and the linux world seems to cut off the old deps: Maybe this is the right time to hire some designers, which can create a (maybe already) GTK4-based, future proof, GUI for Ardour (9 or 10)?
I am no dev or designer, so I just have an vague idea, what will it take to rewrite all the “ancient” code. But maybe this is a necessary step to make Ardour even better?
edit: I just fould old posts from 2020. So maybe there are new thoughts about this.
How much hands-on experience do you have with GTK4 apps? Have you used any that have nested menus made with GtkPopover? Would you willingly use that all the time? Why?
IMO even more than staying on GTK2.
IDK, that’s why I am asking. Even f’n oldschool GIMP now left this behind.
Have you used any that have nested menus made with GtkPopover?
My workflow is 95% hotkeys and mouse. I used to use an external controller, but got rid of it 2-3 years ago.
What’s the benefit of staying on GTK2?
In my experience, many users say “don’t change anything”. But if they do, 99,9% will stay and adopt the new GUI or workflow and get used to. Maybe they are looking back and feel guilty for saying “conservative” things.
what will it take to rewrite all the “ancient” code
Litteraly years of work just to port the exising (= no updates for a long time as well), with absolutely no guarantee to make things “better” in the end.
How GIMP did it? (yea close to no updates) But why they did it? Not because they want to show, that it is possible, but it has benefits, more modern workflow posiibiliies etc.
Simply put, nested menus with GtkPopover mean you need to make extra clicks to navigate between different hierarchy levels. You also don’t get to see sibling menu items of the parent menu. That’s navigation nightmare. It can be somewhat remedied with action search, except GTK has no standard way to do that (unlike KDE Framework apps), so everybody (GIMP, Dune3D, etc.) does it in their own way.
Until Wayland completely replaces X11 on Linux? A lot. You get to implement things that users really care about.
Not sure what the part about “close to no updates” means or refers to.
GIMP had three major issues with GTK2: 1) patches for GTK2 would sit unapplied, which added a maintenance overhead, 2) some HiDPI issues were severe (but now they have other HiDPI issues with GTK3), 3) the graphic tablet stack was “broken beyond repair” (quoting mitch). Of that, 1) somewhat concerned the Ardour team, 2) and 3) don’t apply.
Future benefits? For what program? Ardour? I can only think of Vulkan-based UI rendering. GTK is still a very generic toolkit that is not useful for programs like Ardour. If you need some technical background on that, there is probably nothing better than a 5yo interview I did with @paul here: Libre Arts - Podcast ep. 002 - Paul Davis on the deep rewrite of Ardour (search for “Okay, let’s talk about GTK.” and read on).
Not really. Ardour 8.4 internalized the toolkit, based on a patched and extended GTK+/GDK2.
This helps to be future proof in the way that once Linux distros drop GTK+2, Ardour can still be compiled there by 3rd parties.
For Windows and macOS users there is no difference; the GDK interface there is stable. On GNU/Linux Ardour, like many apps, will require X11 compatibility (XWayland … or what comes next).
Migrating to something else would take 2 - 3 years without any other development happening. Also Gtk+4 or QT does not provide anything to users that Ardour does not already have. In fact it would remove features such as multi-touch.
Keep in mind that Ardour only uses GTK+ for basic UI items (checkboxes, menus, file-browsers) and GDK for window and event abstractions.
I really enjoy GTK4 and libadwaita, but things are always changing. I guess porting Ardour to gtk4 would take as much time as the next new thing to come out from gtk.
If Ardour was to use GTK4, you’d not see any difference at all. libadwaita or other rendering engines would have no effect, since 99% of Ardour’s UI uses custom widgets. Waveform display, faders, VU meters, bindable tri-state buttons… not to mention a custom color theme.
No toolkit provides widgets for those. The same is true for audio plugins.
Authoring apps are rather special in that way. Have a look at blender.org; same thing, or any other non-linear editor…
If Ardour was to use GTK4, you’d not see any difference at all. libadwaita or other rendering engines would have no effect, since 99% of Ardour’s UI uses custom widgets. Waveform display, faders, VU meters, bindable tri-state buttons… not to mention a custom color theme.
Now it makes more sense in my head, Ty @x42 and @prokoudine .
Then maybe Ardour is just not the right tool for me, although I really like many things, I really dislike the GUI. But this is a me-problem.
(I even thought about learning some GUI designing tools like Glade, just to make mockups for Ardour. But it may just be waste of time, when everything is hardcoded and will probably never be on the (glade supported) libs?)
You can’t do any UI development in Ardour with Glade or a similar rapid development tool. That was one of the major challenges for the Waves folks when they were working on Tracks Live (a fork of Ardour).
They are fine for smaller apps, even audio/MIDI-related ones like your Millisecond (which I’ve just featured on Libre Arts) or Gergo’s SysEx Controls.
There is a substantial lack of more complex software written in GTK4. I mean, sure, there’s Dune3D and Horizon EDA, but the developer of both used to be rather unhappy with GTK4 and thought he made the switch from GTK3 too soon. And Zrythm’s developer famously dropped GTK4/libadwaita entirely and switched to Qt/JUCE.
You can also look at something like Siril, astrophotography software. It’s not even GTK4-based yet, merely GTK3-based. But it already has all the hallmarks of a complex application written with newer GTK3 tech and struggling to present all its complexity in a usable manner.
I would think ideally a mission-critical application like a DAW (or an NLE) spread over years of sessions should avoid flavour of the week toolkits like the plague. It seems Ardour is doing this in a way by forking, internalizing and adapting GTK2 for it’s own purposes. Another Linux example of this is the Cinelerra Video editor which admittedly has a pretty ancient and crude toolkit-agnostic UI of it’s own but it is not bothered in the least by the usual GTK/Qt abandon-your-young absolute madness.
Jumping from GTK to QT is simply a ‘same sh*t different day’ proposition. I think the Ardour team has done the most sensible thing they can do by taking what they have and making it their own and I’m also extremely thankful that they’re not chasing after Wayland… this is how common-sense people with long-term professional support in mind do things not by adopting the latest trends…
If you love GTK4 enjoy using Gnome DE, what does that have to do with the applications? Is Kdenlive supposed to switch too so it all matches…? There is also the option to change Ardour’s theme palette so you could make a libadwaita colored theme if wanted.
IMO one of the strengths of libadwaita and gtk4 is that it’s very opinionated. It pushes you to design an app that fits the Gnome look and feel. As a developer with little design knowledge that’s very useful as long as you use the existing widgets.
I can see how that can be useless or even annoying whenever you want to do something that strays from that path.
I’m currently in the (painful) process of porting the GUI ‘engine’ I use for plug-ins to be Wayland native on Linux. Its more a proof of concept than anything at this stage (I anticipate that plug-in UIs on Linux will require X11 for some time, which kind of implies that host applications must too, which I assume would also mean that moving to newer toolkits e.g.GTK4 might not be possible yet?) with as far as I know, no official Wayland support in any of the commonly used plug-in formats, apart from an (unofficial) VST3 extension used by Presonus Studio One for Linux - seemingly the only Wayland native linux DAW.
Porting to any new UI toolkit is a huge amount of work, and mostly all you can expect is that - for users - it will work almost as well as it used to. (FWIW I’m discovering that Wayland has some hilarious ‘quirks’ too, such as the application must provide the window decoration (if you’re using GNOME that is, so basically you have to assume that requirement is mandatory everywhere just in case), keyboard auto-repeat is expected to be managed / implemented by the application, as are mouse cursors - as in you literally you have to supply the ‘standard’ bitmaps yourself - so plenty of opportunity for wild variations in theming, cursor scaling and also keyboard behaviour between applications), several different incompatible clipboard protocols, some experimental, so good luck dragging and dropping files between different applications… to name but a few. Progress I guess.)
Yes I know that. What I mean is if plug-ins are tied to using X11, then the host probably is too, which means the host moving to something newer (which might be Wayland native), like GTK4 I assume, might not be possible?
)