Zrythm Digital Audio Workstation Abandoning GTK For Qt6

[drummer]

Without developers creating multi platforms using GTK, it's hard for GTK to grow as a multi platform toolkit, at the same time, developers may not be willing to put their effort on something they don't know if it will thrive. QT is more mature in this area, mainly because developers buy licenses which puts money to support the development of such features. CopyQ, the clipboard manager, as of today, shows strange behavior on my Mac, and does not work on my Gnome on Wayland. QT is ahead, but not perfect is my understanding (I'm NOT an expert on both toolkits).

[lowflyer]

Apparently nobody in this forum can see the elephant:

The C language has reached the end of life

This move from the Zrythm devs shows it. They say it almost directly in their statement. Expect more projects to follow suit. And NO, C++ bindings do not make a C-library fit for C++. Even if the library is designed with object orientation in mind, (like e.g. FFmpeg) it still sucks to have to use such a library in a C++ project. There is much more to modern C++ than "C with classes".

The one thing that I don't like to see is that they intend to use JUCE and QML. JUCE is a commercial product and QML is a vendor-lock-in trap. Both are not so brilliant options for open source projects.

[sunlight]

Phoronix: Zrythm Digital Audio Workstation Abandoning GTK For Qt6

Zrythm is an interesting open-source digital audio workstation (DAW) software package. It's been making use of the GTK toolkit but now the developers have decided to switch to Qt6 instead...

https://www.phoronix.com/news/Zrythm...ing-GTK-For-Qt

Have you ever tried slowing your music like a record by allowing pitch to go down?

For some music it can be quite relaxing, so give it a try.

For streaming music, the browser addon "global speed" with the **allow pitch shift** turned on, is the same as slowing down records or tapes.

[stargeizer]

Apparently nobody in this forum can see the elephant:

The C language has reached the end of life

This move from the Zrythm devs shows it. They say it almost directly in their statement. Expect more projects to follow suit. And NO, C++ bindings do not make a C-library fit for C++. Even if the library is designed with object orientation in mind, (like e.g. FFmpeg) it still sucks to have to use such a library in a C++ project. There is much more to modern C++ than "C with classes".

The one thing that I don't like to see is that they intend to use JUCE and QML. JUCE is a commercial product and QML is a vendor-lock-in trap. Both are not so brilliant options for open source projects.

Wrong.

The language used in GTK has nothing to do with the fact that GTK is fast and useful on Linux, but on ther OS is quite shitte: It was never properly ported to other platforms. That's all the problem of GTK vs others.

The windows port of GTK was mostly a one man show that just hacked it on top of the old win32 API, and is barely mantained even nowadays. Nowadays the Win32 API is deprecated and keept only for backward compatibility. The mac port is barely integrated into Cocoa, and is just another s**tfest. This is the reason why applications written on GTK for Linux cannot be ported directly for MAC o Windows: It requires some ugly hacks to be coded into the port.

QT is not exactly the best option, because is can bite hardly when they decide to deprecate something and remove something without proper warning (this is changing for their paid customers), but it guarantees that if you code a GUI on any OS, it will work on any supported OS. (except if you are using QT on Wayland, but that's wayland problem, rather than QT problem) GTK requires quite the effort from the coder to be used, built, and even then, "Results may vary".

C or [Insert your favorite language here] has nothing to do with it. It has more to do with insanity, more than anything else.

[mobadboy]

while gtk is generally second only to iced on linux and freebsd, it is also true that it is almost as bad as wxWidgets on windows.

i wonder why they didnt use iced instead of qt, when trolltech can stop it any day

[lowflyer]

Wrong.

Can you please elaborate on that? What exactly is wrong and in which way? The "explanation" you add tends to confirm what I said:

• C has reached the end
• C++ bindings are insufficient to salvage C-libraries
• more projects will follow and upgrade their languages away from C
• I criticized the decision to use JUCE and QML

Not a single word of my post says that GTK is bad or unusable. I do have experience with MFC, Wx, GTK, Tk and Qt on both, Linux and Windows. I can honestly say that GTK has the most solid API of them all. With "solid" I mean "promises given in the documentation matching exactly the outcome" in your code.

The language used in GTK has nothing to do with the fact that GTK is fast and useful on Linux, but on ther OS is quite shitte: It was never properly ported to other platforms. That's all the problem of GTK vs others.

GTK is fast and useful on Linux because most Linux applications are written in C. But exactly this makes these "ports" to operating systems written in other languages so difficult. Contrary to what you say, there is an influence that the used programming language has. It does not make it "unusable" - just more difficult.

The windows port of GTK was mostly a one man show that just hacked it on top of the old win32 API, and is barely mantained even nowadays. Nowadays the Win32 API is deprecated and keept only for backward compatibility. The mac port is barely integrated into Cocoa, and is just another s**tfest. This is the reason why applications written on GTK for Linux cannot be ported directly for MAC o Windows: It requires some ugly hacks to be coded into the port.

Ask yourself *why* it is that way. Why are so few programmers out there that want to take up the slack? Have you worked with gobject's in e.g. C++ yourself? These coders have easier alternatives available to them. Realize that Wx and Qt fill voids that are not addressed by GTK.

QT is not exactly the best option, because is can bite hardly when they decide to deprecate something and remove something without proper warning (this is changing for their paid customers), but it guarantees that if you code a GUI on any OS, it will work on any supported OS. (except if you are using QT on Wayland, but that's wayland problem, rather than QT problem) GTK requires quite the effort from the coder to be used, built, and even then, "Results may vary".

You describe exactly why coders prefer Qt over GTK. You write: "GTK requires quite the effort from the coder..." A lot of that effort is simply not required with Qt. I did not say that Qt is "the best option". But it is hands down the better option than GTK. Especially if the coders intend to use C++. GTK may be a viable (or better: a familiar) option if the project is completely written in C. But as I said earlier, the C programming language is on the way out.

C or [Insert your favorite language here] has nothing to do with it. It has more to do with insanity, more than anything else.

Can you please elaborate what you mean by this. Who do you accuse of insanity?

The programming language of a library actually does matter. While it is no problem to use a C-library in a C++ project, the other way around is usually not possible. If you want to google it, the magic term is: ABI (Application Binary Interface). C sits almost at the lowest level of the hierarchy, just above assembly language. Every higher order language interfacing with a C-library needs to translate its higher order objects into something that can be understood by C. This additional work can be avoided with a careful selection of the library. This alone is the reason why Qt fares better than GTK these days. Even with the problems that Qt has.

[FreeFull]

while gtk is generally second only to iced on linux and freebsd, it is also true that it is almost as bad as wxWidgets on windows.

i wonder why they didnt use iced instead of qt, when trolltech can stop it any day

Zrythm is written in C++. Qt is also written in C++, while Iced is written in Rust, so it's a lot easier to get Qt working with a C++ codebase

[skierpage]

Didn't Firefox remove XUL years ago because it's renderer and parser were hot garbage and nobody knew how they worked enough to fix bugs? AFAIK, all XUL files were purged from mozilla-central as of 2019. They utilize HTML now iirc.

Not quite. Mozilla renamed all the XUL files that laid out elements of browser windows to .xhtml files. But those XHTML files still embed lots of XUL elements by referencing the xul namespace (with the infamous URI xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"). For example the picture in picture video player still has a lot of XUL elements like <xul:commandset> . These could be, and many have been, replaced with "web components" built in standard HTML technologies of custom elements, shadow DOM, and HTML templates (which simply didn't exist when Firefox was created), but it's a lot of work and there are some XUL features that pure HTML can't do. Bug 1563415, [meta] Start using HTML elements to replace XUL elements, tracks the progress.

There was a separate project to get rid of another technology XBL (XML Binding Language) which Mozilla used to define the appearance and behavior of UI components. That is completely gone; don't ask me to explain the difference between XUL and XBL. People like to rag on Firefox but its declarative layout of UI using XHTML-like markup file decades ago was hugely influential to XAML and QML