Ardour 8.4 maintains its GUI toolkit in its source tree

[bluebell]

See https://ardour.org/whatsnew.html

What's hip today is outdated tomorrow. It seems that the Ardour developers have realized that the only reliably available GUI toolkit is the one that you maintain yourself.

Doesn't that remind us of many plugin developers' way to handle it?

[Audiojunkie]

See https://ardour.org/whatsnew.html

What's hip today is outdated tomorrow. It seems that the Ardour developers have realized that the only reliably available GUI toolkit is the one that you maintain yourself.

Doesn't that remind us of many plugin developers' way to handle it?

It's really not a bad idea at all. GTK2 is solid and road tested. The only thing bad about it was the lack of high resolution/hidpi scaling support. The ardour developers have already added that into their program themselves. They've been statically linking to GTK2 for years, with no negative effect. The only thing they've done is remove it as a dependency (by incorporating the code into the actual Ardour source). This won't have any more negative effect than developers that use frameworks such as JUCE, WxWidgets, FLTK, etc. The only negative that I can think of, would be the lack of native wayland support. But then again, that's what XWayland is for, and that's not going to go away for at least 20 years. They can make much better use of their time by doing this. Plus, this makes it so that all of the distro maintainers can compile the whole program without having to worry about the depreciated GTK2 being a missing dependency. I think it was a good move!

That said, when XWayland does lose support, they will be in a world of hurt. Hopefully I'll be dead by then.

[natalie321]

Both Ardour and plugin developers face a trade-off. Using existing toolkits is faster but less customizable while creating custom UIs offers more control but takes more time and effort.

[tramp]

Using existing toolkits is faster but less customizable

That's not really true. Ardour, for example, using nearly only customized GTK widgets ( means own developed widgets), and so does Guitarix (Gtkmm). The more work to create a widget toolkit is behind the scene. So, handling list-views, menus, combo-boxes, file-browser, create a event loop, handle mouse input/movement, keyboard input, ensure memory safeness, etc. All that is easy to use from existing toolkit, but takes a lot, lot of work to create from scratch. The widgets you see afterwards on the GUI been easy and fast to develop, as easy as customize a existing toolkit.
That's the reason why Ardour stay with GTK2 and implemented it in the source now, while it reach it's end of life in nearly all distributions.

[Impostor]

Using existing toolkits is faster but less customizable

That's not really true. Ardour, for example, using nearly only customized GTK widgets ( means own developed widgets), and so does Guitarix (Gtkmm). The more work to create a widget toolkit is behind the scene. So, handling list-views, menus, combo-boxes, file-browser, create a event loop, handle mouse input/movement, keyboard input, ensure memory safeness, etc. All that is easy to use from existing toolkit, but takes a lot, lot of work to create from scratch. The widgets you see afterwards on the GUI been easy and fast to develop, as easy as customize a existing toolkit.
That's the reason why Ardour stay with GTK2 and implemented it in the source now, while it reach it's end of life in nearly all distributions.

Psst. Bot alert.

[Paul Johnson]

See https://ardour.org/whatsnew.html

What's hip today is outdated tomorrow. It seems that the Ardour developers have realized that the only reliably available GUI toolkit is the one that you maintain yourself heardle

Doesn't that remind us of many plugin developers' way to handle it?

The only downside was the absence of high-resolution/hidpi scaling support, but the ardour developers have already addressed this by adding it to their program.