Hacker News Reader

Comment by cprecioso | Hacker News Reader

It was using wxWidgets, not GTK directly IIRC

Ah, the dream of "one UI toolkit to rule them all" was very much alive when wxWidgets got popular around the turn of the millennium

Back then it was wxWindows, but yes. Also I'm told it had a lot in common with MFC.

On a different corner of the open source ecosystem, PrusaSlicer, also a wxWidget project, just announced the first of its v3 releases with a full GUI rewrite, and what a blast from the past it was to have a X11, non-scaled, wrong font & dpi. It's really unfortunate that they didn't take the opportunity to switch to Qt

Most people that have never maintained >=Qt5 projects assume free wxWidgets native cross platform OS interface support is less hassle.

Refactoring the application core means their team should have forked the project to audacity-qt rather than inject long term Qt library and license dependency issues into the original package.

Qt on occasion has proven to cause problems with license term changes, GL library bugs on Linux window managers no one ever fixes, and a chain of legacy build issues.

Microsoft people tend to design around entertainment eye candy rather than functional long-term reliability. A interface use-case context pop-up isn't a design choice, but rather just chaotic depending on who is using the seat.

The Audacity 3 interface certainly needed a lot of work, but nuking it for v4 re-write is simply packaging a different program as the original.

Hopefully the remake works out. The odds are not in their favor though... =3

https://en.wikipedia.org/wiki/Second-system_effect

My understanding is that the Qt 6 build system is vastly easier to work with.

Also, Audacity is not the first major FOSS project to successfully migrate from wxWidgets to Qt: Dolphin, the GameCube/Wii emulator, made a similar migration several years ago[0][1][2][3].

[0]: https://dolphin-emu.org/blog/2017/06/03/dolphin-progress-rep...

[1]: https://dolphin-emu.org/blog/2018/02/03/dolphin-progress-rep...

[2]: https://dolphin-emu.org/blog/2018/05/02/legend-dolphin-lens-...

[3]: https://dolphin-emu.org/blog/2018/07/06/dolphin-progress-rep...

>Qt 6 build system is vastly easier to work with.

The Audacity team imported their existing Qt interface code from a previous project. Depending on the design, the code smell could have a lot of vestigial parts unrelated to the new project.

I have always seen FOSS as the last stop for public domain software. It is supposed to become the stable road future kids walk down to become professionals. The Qt framework is often antithetical to that goal in my opinion. =3

Rule #3: popularity is not an indication of utility.

I recall (could be wrong, talk from the top of my head), VLC also did it years ago.

You are correct, but did VLC become more stable and easier to maintain? Maybe... =3

I don't know, it took me a while to get used to but i actually prefer Qt6+CMake over Qt5. Porting the first application was kind of a nightmare due to how many things i had to change.. though they were code smells to begin with, now everything run smoothly.

Could also look at https://quasar.dev/ if you do rapid release cycles. =3

imagine picking some Vue framework over Qt when talking about "the stable road future kids walk down to become professionals". There's software written today in Qt that traces back all the way to the mid 90s and are still top-of-the-line for their business.

The project I'm working on has been based on Qt since Qt 4 era, has been through people vouching for JavaFx, Angular, JUCE, React, Electron, and a dozen other frameworks over Qt, and had entire competitors based on web tech come and wither. How many Vue software will still be written in Vue 20 years from now ?

Structurally, Qt is sometimes worse given the compatibility issues. There are desktops where Qt5/Qt6 software runs fine if you can get it to compile, but the GL interface has been broken on many platforms for over a decade.

If folks don't plan on maintaining things after a release cycle it no longer matters how one ports disposable code. On mobile the App life cycles are short. Quasar does exactly what Qt has been doing for years, but just abstracts the compilation pipeline for each MacOS/Win11/Android/iOS/Linux platform. For simple stuff it works fine, and generates solutions in under an hour.

>How many Vue software will still be written in Vue 20 years from now ?

Probably all of them in their bloated glory, as the build artifacts do not rely on a single unstable external fragile framework library heavily coupled to the operating system releases.

Personally I prefer wxWidgets for desktop, but it is not appropriate for every project. =3

> There are desktops where Qt5/Qt6 software runs fine if you can get it to compile, but the GL interface has been broken on many platforms for over a decade.

do you have example / bugreports of this ? for my app I run tests across a wide range of laptops, platforms and distros, across nvidia / intel / amd / llvmpipe / ... and it all works fine. hell, with the help of Claude I managed to port back the current dev branch of Qt6 back to Windows XP, with working OpenGL.

I am not suggesting your experience isn't true, but personal exposure to Qt over the years has not been as easy going. ymmv

Best of luck, =3

They went over why switching to Qt was the best option for their team here: https://youtu.be/QYM3TWf_G38?t=840 .

I actually alluded to the design choice compromise in my post. But thank you =3

Reply on news.ycombinator.com