Using WxWidgets Qt backend?

[falkTX]

This is more of a question rather than a feature request.
As Musescore is done in Qt and Muse Group is hiring Qt developers, seems the interest is on Qt things.
Audacity is an old codebase, changing the entire toolkit is not a good decision at this point, too much core elements rely on WxWidgets.
If everyone working in the codebase is familiar with the same toolkit (say Qt) it makes the overall process much smoother.

Now with that said, WxWidgets has a WIP Qt backend.
Find more details in https://wiki.wxwidgets.org/WxQt

So I am opening this ticket to bring a discussion around this topic.
I see a few clear benefits from such move:

1. Easier to maintain, as less platform-specific solutions are needed (whatever WxWidgets does not do, Qt will)
2. Consistent look across all platforms (Qt allows custom themes)
3. More integrated into what Muse Group devs are working with right now.

I am not just opening a ticket to request things, I actually went ahead and spent some hours to try this out.
There are a few places in Audacity where code needs to be adapted, but it is only a few days work maximum.
I was able to hack around in a few places in Audacity code to make everything build and run.
As a bonus, I threw in my own custom color palette and style that I use in Carla.
Here are a few screenshots to show the result:

native file dialog through qt:

Colors can be changed of course, I just like this style in particular. It is a slightly modified Fusion theme from Qt.

Now the main question is... is there interest on this?

WxWidgets Qt backend is still work-in-progress yes, but on the other hand Audacity does not need the entire thing.
Fixing WxWidgets Qt side (and then submitting patches upstream) could be a way forward here.

Looking forward to comments and/or opinions.

[Be-ing]

Consistent look across all platforms (Qt allows custom themes)

To clarify, does the theme come from Qt or wxWdigets? Sharing a Qt theme between Audacity and MuseScore could be an interesting idea.

[falkTX]

Theme is from Qt side.
Qt themes are done in C++, but there are a few "theme engines" like https://github.com/tsujan/Kvantum/tree/master/Kvantum that allow for SVG asset rendering.

EDIT: An extra note worth considering, is that Qt allows for applying CSS-like stylesheets on top of application widgets. So as long as each widget object name is defined, one can theme things with CSS 🤩

[imciner2]

The wxQT backend is somewhat minimal currently - and if I recall only one main group was contributing to it for their own app support. There are many places in it that may end up just not working because parts haven't been implemented (one major place that hasn't been implemented is the OpenGL support and wxGLCanvas).

[imciner2]

Also, switching to the wxQT backend is a lot more work for packaging on Linux than just switching to QT, since linux distros don't build anything other than the wxGTK backend normally.

[falkTX]

From what I have tested and saw in the code, a lot of stuff already works. Some drawing issues seem to be due to transparency being used, so perhaps the ghosting is fixed by a simple Qt::WA_OpaquePaintEvent in the right places.
I didnt check OpenGL related things, is Audacity using those?

On a somewhat related topic...
I do not know what are Muse Group plans for Audacity, looking at the recent commits it seems to me the intention is to make an engine out of Audacity to be usable on some new GUI (is that what QML is for?)
Doing a brand new GUI from scratch is a lot of work, compared to fixing up something that mostly works already.
The fact that the same style could be applied to Musescore and Audacity (while retaining Audacity's iconic UI) is worth a lot.

[SteveDaulton]

There's also the much requested "Audacity for mobile" to consider. Does wxQt support Android or iOS yet? The last time I looked, it didn't.

[falkTX]

Desktop widgets make no sense for mobile, and the current design does not fit well into touch input.
So even if WxWidgets + Qt could be made to work on mobile, a brand new Ui is needed there. Start with the simple stuff than slowly add as much as possible from the main Audacity.

[JamesCrook]

I am really keen for us to move to Qt. That will make so much difference.

@falkTX - Could you say more about the issues?

Is this looking like a good stepping stone to full Qt? Is there a sharable GitHub link so that we can see what you've done so far?

[Be-ing]

I was more commenting on the fact that Qt can render the whole application on top of OpenGL, rather than we using individual widgets.

Really? How? I am not aware of how to do this. IIUC QOpenGLWidgets are rendered on the GPU separately from the CPU rendered QWidgets and composited together by Qt.

Anyway, using OpenGL directly may not be a great idea for future proofing. I do not know if you are aware, but Qt6 moved to a new abstraction layer over OpenGL, Vulkan, and Metal for optimal cross platform performance. Qt6 has a new tool (Qt Shader Baker) that compiles Vulkan-compatible GLSL shaders for each of these backends.

In fact, it is not fast enough for smooth usage on a PinePhone, so I already abandoned the idea of using it for personal projects.

That does not match my experience. The animations in Plasma Mobile and Elisa look smooth and slick on my PinePhone (I am using Phosh currently because Plasma Mobile is not yet packaged for Fedora).

[falkTX]

we are getting way off-topic here, but eglfs is one example of the whole qt running on top of opengl (GLES to be exact)

I am using Mobian on the phone, maybe time to try something else.
Note that I am not talking about looks, but performance. The few QML based tools/"apps" I tried all had subpar performance, UI was visibly sluggish. But I will try the kde distro build and give it 2nd change then. Thanks.

[Be-ing]

https://doc.qt.io/qt-6/embedded-linux.html

In addition to Qt Quick and native OpenGL applications, EGLFS supports software-rendered windows, like QWidget, too. For QWidget, the widgets' contents are rendered using the CPU into images, which are then uploaded into textures and composited by the plugin.

I'm not sure Qt's EGLFS platform plugin can be used within a Wayland compositor anyway.

Yes, I am talking about performance too. Qt Quick's animations look smooth on my PinePhone. I don't think this is getting off topic. The question is what would be the benefits of switching to Qt. Smooth animations on a low spec mobile device like a PinePhone would be a nice benefit. Give postmarketOS or Manjaro with Plasma Mobile a try and see for yourself (though heads up, audio playback stutters horribly on Manjaro).

[lengthwave]

PS: I am available for hire ;)

The info you have provided here is super helpful.
I'm a big fan of the other projects of yours and use some of them quite often.

I am definitely interested to talk.

I'll send you and email directly.

[Be-ing]

There is also a chance to share gui code between musescore and audacity with a move to qt.

Considering MuseScore is moving to Qt Quick from QWidgets, this would be facilitated by using QML in Audacity.

[falkTX]

I started a clean experimental branch for wxQt over at https://github.com/KXStudio/audacity/compare/master...KXStudio:wxqt
But it is blocked by #882 as we need a clear decision on how to use os-target macros.

[KAMiKAZOW]

too much core elements rely on WxWidgets.

Maybe that should change and over time get Audacity ready for a full Qt port.

[Paul-Licameli]

Felipe, thank you for the suggestions.

I have contributed to Audacity since 2014 and been a team member since 2015. I have learned enough wxWidgets for my purposes but have little familiarity with Qt.

Rather than gaining that familiarity, what occupies me instead is enlarging the parts of the program that are TOOLKIT-NEUTRAL. It’s the notion of good “model-view” separation. Great parts of the program, like the mathematics or the persistency or the audio engine, should be independent of the choice of toolkit used for drawing widgets.

Having achieved that neutrality, and separated large parts of Audacity into libraries, then perhaps we could contemplate multiple Audacity products implementing different user interfaces. A classic desktop Audacity and a concurrently maintained tiny Audacity for phones, perhaps?

Much code has accumulated in twenty years that did not observe this neutrality principle very well, but it has been my labor in recent years to correct that with various restructuring transformations. See commit history. My name occurs a few times.

wxWidgets and Qt both are old enough projects that they date from a time when the C++ standard library was not well advanced or well implemented everywhere, and so they both reinvented (or preinvented) many wheels for strings, containers, files, threads, etc. In these times, it would be better to use standard C++ for these things where you can, but the reality is that the use of wx equivalents is pervasive in Audacity. However I don’t see this as an obstacle. Linking to the wxBase subset of the non-monolithic build of the wxWidgets libraries, for such utilities, is consistent, I think, with toolkit neutrality. So we can avoid wasting effort on rewrites of the wrong wxWidgets things.

(Still we should be restricted in the library layer only to a subset of wxBase, which includes enough for console applications, and that does not exclude event handling such as for timers. It does contain support for a main event loop.)

When it comes to putting new Qt skin on the old toolkit neutral guts, what you did may be a shortcut to a change of look-and-feel.

But for enabling QML development — I’m not sure that the retargeting to wxQt really helps. I had thought that, barring painful workarounds, a user interface must be all or nothing wxWidgets or Qt because there can be only one main event loop.

But do I misunderstand? Is there a way to do hybrid UI programming, transitioning parts of the interface from wxWidgets incrementally, enabled by wxQt? Educate me.

[Be-ing]

It is also possible to drive Qt's event loop with a different event loop. For example, Whisperfish uses Tokio to run the Qt event loop. I do not mean to imply that would necessarily be the best solution in this case, but it may be worth considering.

[Be-ing]

should be perfectly (read: technically) possible to mix regular desktop Qt with QML.

I presume by "desktop Qt" you mean QWidgets? It is possible to mix QWidgets and Qt Quick, but there are significant limitations. There might be more performance limitations now in Qt6 with QRhi; it looks like that documentation might not have been updated to reflect those yet. If you will do a ton of work to switch toolkits, I recommend not using the legacy QWidgets.

[Be-ing]

You can use the C++ standard library for a lot, but if you interface with Qt APIs, you'll need to use Qt data structures.

[Be-ing]

multiple Audacity products implementing different user interfaces. A classic desktop Audacity and a concurrently maintained tiny Audacity for phones, perhaps?

This old way of maintaining separate applications is not necessary anymore. You can use KDE's Kirigami QML library to make one application that works on any screen size (there's also libadwaita in the GTK world), including on Android. I'm not sure if you could legally distribute that in the iOS App Store though.

[Paul-Licameli]

You can use the C++ standard library for a lot, but if you interface with Qt APIs, you'll need to use Qt data structures.

Surely, where you must use Qt APIs in an API layer of code, then you will adapt as needed.

I don't want Qt data structures in core layers, making unnecessary dependencies of those layers on certain libraries.

[Paul-Licameli]

I don't know enough to see why you prefer QString to std::string (or std::wstring). A glance at Qt 5 documentation for smart pointer classes makes me think the standard pointers are superior (move semantics).

For a fun time, study TranslatableString in Audacity, an invention of my own, allowing (1) static type checking that prevents a mixing-up of strings that are meant for users to read with those used for other purposes, and (2) binding of arguments to positions in a formatted string, before doing the substitution, which may depend on the global setting of preferred locale, which may in turn be changed at some time after the construction of the string object.

[falkTX]

Latest versions of Qt are quite okay with C++ adoption (including move semantics).
Qt takes backwards compatibility pretty serious, so supporting stuff like that can't be done quickly. Old Qt4 will never properly have them.

The stuff with strings is just an example. If you want to do stuff like "string.endsWith(x)" or "string.replace(x, y)" or any other sort of expected method for a string class you end up having to deal with inner std stuff.
This is what I came up with for a std string endswith, just for a reference:

inline bool ends_with(const std::string& value, const std::string ending)
{
    if (ending.size() > value.size())
        return false;
    return std::equal(ending.rbegin(), ending.rend(), value.rbegin());
}        

[Paul-Licameli]

This might do it in C++14:

ending.rend() == std::mismatch(ending.rbegin(), ending.rend(), value.rbegin(), value.rend())

But regardless, I'm not finding that example compelling enough to make me want to use QString everywhere.

I'd like to see Qt usage kept confined -- used for GUI in code for a GUI layer. Don't use it in what should be toolkit-neutral code.

It's tolerable for now that wxString instead of some other string class is used everywhere. It would be better but tedious and not a high priority effort to replace all that with the standard library strings.

I would not consider it good to replace wxString with QString everywhere, trading pervasive dependency on one non-standard toolkit's reinvented utility wheels, for those of another.

It would be very bad to let a mix of wxString and QString start infesting those layers.

[falkTX]

This might do it in C++14:

ending.rend() == std::mismatch(ending.rbegin(), ending.rend(), value.rbegin(), value.rend())

But regardless, I'm not finding that example compelling enough to make me want to use QString everywhere.

Well imagine having to do something like this for every single string operation required. and it is not just strings, other core classes have similar behaviour.
a mini-lib is needed in order to make std::string pleasant, in my opinion.

I would not consider it good to replace wxString with QString everywhere, trading pervasive dependency on one non-standard toolkit's reinvented utility wheels, for those of another.

It would be very bad to let a mix of wxString and QString start infesting those layers.

Of course, and I agree completely. It should be all either in one side or the other.
(or all in pure c++ code if that is really wanted, why not)

[KAMiKAZOW]

So, is this matter being still being pursued or was Muse Group's quest to drive off contributors successful?

[SteveDaulton]

I think I speak for many developers here in saying that we do not want our contributions to a GPL-licensed project to end up on closed-source applications.

Thanks for the clarification. I understand, but I disagree with that position as it effectively rules out anything under an MIT or BSD style license. I do support and uphold your right to that stance, though I find it mildly offensive that you characterize it, and by implication anyone that disagrees with you on this point, as "disgusting". Time to move on - thank you for taking the time to explain, and best wishes for all of your open source project.

[nyanpasu64]

Contributing to a MIT-licensed coeebase allows everyone, including yourself, the company owning the codebase, and others, to develop proprietary products based off the codebase. Contributing to a GPL+CLA codebase is giving special permission to one company to make or sell proprietary products based off your work, which is not a level playing field.

[falkTX]

I want to move on from the conversation myself too, excuse me to just clarify one point.

I find it mildly offensive that you characterize it, and by implication anyone that disagrees with you on this point, as "disgusting"

I am not saying that contributing to MIT/BSD/ISC and similar licenses projects is "disgusting", far from it.
One of my main projects, DPF, is licensed this way precisely because the target is to allow it being used in commercial products.
There are absolutely no problems contributing to a project that is licensed the same way, we know by the license what is allowed and what is not.
Everything surrounding LV2 is liberally licensed for this reason, we do not want to act as gate-keepers and prevent commercial/closed-source use.

What is disgusting are contributions made to a GPL project later appearing on a closed-source product.
The GPL is designed to prevent that, and when we dont have that anymore, it basically takes away the reason the GPL was created for.

[Paul-Licameli]

Contributing to a MIT-licensed coeebase allows everyone, including yourself, the company owning the codebase, and others, to develop proprietary products based off the codebase. Contributing to a GPL+CLA codebase is giving special permission to one company to make or sell proprietary products based off your work, which is not a level playing field.

Pleased to see you here, nyanpasu64. You have contributed one fine feature already to Tenacity in the Plot Spectrum improvements. There is more than rebranding and retheming and build system changes now. Good work.

[Paul-Licameli]

But I refer to this irony: https://github.com/tenacityteam/tenacity/graphs/contributors

That is just an artifact of "contribution inertia". If you limit to contributions since the 1st of June it shows a more accurate view on the lifetime of the fork.

...

That said it is indisputable that currently the majority of the Tenacity code base consists of code acquired from the fork.

Tenacity's CONTRIBUTING.md makes compatibility with upstream the # 3 guideline. I am continuing work on the upstream (no secret of course). If the Tenacity team will continue down-streaming good things -- as they are fully entitled to do, and as they already have since the fork -- well then I expect to continue to see myself high on your contributors page for long to come.

[zm-cttae]

@falkTX could you kindly make your all-dark build available in some way? The current UI in Windows 🙈

[falkTX]

no, it relies on gtk which is a linux build option.

and anyhow audacity devs are reworking the theme stuff and GUI now, so it is a matter of time until a fresh new modern look appears

[zm-cttae]

I've been using WSL to run a fully dark Audacity workflow and its okay

[barracuda156]

Does anyone know if Qt backend of wxWidgets became properly useful by now?

[barracuda156]

@shmerl I have found out that it apparently is Qt5-only, which does not work for my purposes. My hope was that with Qt4 backend instead of a broken default one wxWidgets will finally work on old macOS correctly (it builds fine now, but does not actually work), but looks like that will be a big endeavor to fix.

[shmerl]

Qt 4 is DOA, it doesn't even support Wayland on Linux and as far as I know, it's not supported upstream anyway. Nothing should be using it.

I think new version is not using wxWidgets in the first place, it's using Qt directly.

[barracuda156]

@shmerl This is obviously unrelated to the thread, but for the record, there are multiple systems where Qt5 is broken, while Qt4 works perfectly fine. If upstream bothered to fix Qt5, we would not have needed Qt4 at all, but it is not the case, unfortunately.

[shmerl]

They are now developing Qt 6 either way and most of the backporting to Qt 5 is done by KDE team, not even upstream Qt developers. I have no issue with them not spending resources on Qt 4 which has zero backing from upstream at this point.

[barracuda156]

@shmerl I do not mean that. What should have been done is to maintain support not just for a few bleeding edge OS versions. Qt4 should be retired, but it cannot be done due to upstream of Qt trashing support for older OS versions and less popular archs.