tenacity-legacy
tenacity-legacy copied to clipboard
tenacityteam
Use Qt or GTK as a frontend GUI
Guidelines
- [X] I have read the guidelines.
Is your feature request related to a problem? Please describe.
Add Qt GUI for Tenacity.
Describe the solution you'd like
Take a look on AudMonkey:
- https://github.com/AudMonkey/AudMonkey/pull/27
- https://github.com/AudMonkey/AudMonkey/tree/qutemonkey
Describe alternatives you've considered
There are no alternatives to Qt.
Additional context
No response
This issue is not a duplicate
- [X] I have confirmed this issue isn't a duplicate.
Impressive stuff! We've thought about porting Tenacity to Qt, but realized that (a) it'll 100% break compatibility with upstream and (b) it'd be easier to build a Qt replacement from the ground up.
Honestly, I don't think we care too much about compatibility with upstream. The only thing I'd care about personally is merging unfinished/half-finished features as seen in https://github.com/tenacityteam/tenacity/pull/515 and audio engine stuff/bug fixes/overflows/minor stuff.
There was another person working on Tenacity that wanted to help bring the application to native GTK too. If we were all to combine our efforts, we'd probably be able to achieve something similar to Transmission, which has multiple frontends written for it that are treated equally.
note: just to clarify, I don't think this is relevant to tenacity as long as this issue isn't being worked on.
There are no alternatives to Qt.
Hello, yes, GTK?
Not trying to sound rude, but the Qt team is honestly not adhering to FOSS culture - they hide bugfixes behind a paywall (qt5.15.2 is the last free version of qt5), and, which is especially important to me, don't seem to care about fixing bugs that aren't paid to fix. There's still a bug in qt5 where qt apps that force updates while offscreen crash when coming on-screen again - the bug report is open since january 2020 and stalling since june 2021, after they've identified the faulty code path and concluded that it doesn't exist in qt6 anymore.
I don't see why gtk3 wouldn't be an option.
There are no alternatives to Qt.
Hello, yes, GTK?
Literally I mean "there are no alternatives good alternatives to GTK other than Qt".
I don't see why GTK3 wouldn't be an option.
First of all, GTK4 is coming.
Secondly, “The problem with GTK is that even after it has reached a major version number (such as 3.0) they are making binary incompatible changes” between minor versions:
- SolveSpace thread: https://github.com/solvespace/solvespace/issues/347#issuecomment-490239648
With Qt there are no such issues.
Literally I mean "there are no alternatives good alternatives to GTK other than Qt".
But Tenacity doesn't use GTK right now, it uses wxWidgets. Very different, especially when talking about all of the main window with its custom controls.
I don't see why GTK3 wouldn't be an option.
First of all, GTK4 is coming.
GTK4 isn't coming, it's been there for 9 months.
Secondly, “The problem with GTK is that even after it has reached a major version number (such as 3.0) they are making binary incompatible changes” between minor versions:
That's borderline FUD and I'm not going to engage in that line of thought beyond this reply.
* SolveSpace thread: [Build an AppImage targeting Xenial solvespace/solvespace#347 (comment)](https://github.com/solvespace/solvespace/issues/347#issuecomment-490239648)With Qt there are no such issues.
I believe there will be much bigger issues if you go do what that linked thing did to Qt, where they ended up mixing different versions of libgdk and libgtk, which come from the same package and work closely together, but they intentionally made to version mismatch. Qt adds and changes some private API that is used between the different components (e.g. qtcore and qtgui), so it would probably blow up quite similar or worse if you go and use e.g. QtCore from Qt-5.5 and QtGui from Qt-5.12. Making conclusions of binary incompatibilities from such an example is inappropriate. Upstream has also replied in https://github.com/solvespace/solvespace/issues/347#issuecomment-492286829 to this stuff.
With that out of the way, I think @panos probably meant me in his comment.
My first preference is to just have a long-term plan to get away from wxWidgets, as its good days are long over - it is at an evolutionary dead end. For example, I don't see how they'll manage to support GTK4 with the current manpower - GTK4 dropped foreign drawing support, so this "native looking drawing, but not native widget NOR own gtk widget implementation in the background" fallback to own things while trying to emulate the native looks isn't really going to work. I do not believe wxWidgets has a future, it feels to mostly just tick along with existing decade or more old projects using it, and a couple of those projects being the children of some of the wxWidgets development team. I drifted away from my old "wxChild", so I haven't developed wxWidgets for well over a decade.
So I believe it is important to have a plan to get away from it eventually, be it to GTK, Qt or whatever else.
My personal preference on how to achieve that would be, as you might guess, to move towards GTK. GTK4 provides a modern toolkit that works on X11, Wayland, Mac and Windows, including making good use of the GPU via its OpenGL rendering backend on all those platforms, albeit implementing things like the audio wave displays with GTK methods that keep using GPU would be a challenge, but not something that needs to be tackled in initial versions - these could be pretty straight ports from wxGraphicsContext and co to cairo at first (well, if those were used, but currently legacy wx drawing API is used instead). It does have some concerns for Windows and Mac, but I'm hearing good things about it from GTK4, but it'd definitely be something to check into closer. I'm otherwise exclusively Linux and haven't had a reason to look into it. In theory we could also convert it gradually to GTK3, but such a mix would only work on top of wxGTK, and I'm not sure wxGTK works with any other GTK backend than X11 and Wayland. It might be possible to make it work on Mac and Windows without TOO much effort - GTK itself and wxWidgets itself in isolation do work, afterall. If not, it'd be only runnable on Linux/BSD GTK platforms until the work is completed enough to switch off the wxWidgets parts.
But fundamentally I think we can choose between two main paths, whatever toolkit we use:
- big rewrite to get away from the legacy code and clean things up
- refactor the UI to be more cleanly separated out and moving away from relying on wxWidgets things (wxString, etc) in the core
I think 1. would be nice, but I don't know if we have the manpower and buy-in for that. I don't think so. For 2. we just need to agree to have it as a goal within the contributors and start actively working towards that and see how far we get. If nothing else, it should lead to a more maintainable codebase on top of wxWidgets still.
So in summary, I do think we should try to eventually move away from wxWidgets, but for the project itself both GTK, Qt and probably some other options are good choices. It matters what has the manpower to get it done. The choice is for those that would actually do the work. Personally I wouldn't do any big work on the GUI parts if the choice ends up Qt, but that's perfectly OK - I'll just be happy to see a good open source audio editor that thrives on top of a modern toolkit.
Friends, you all forked too early.
Retargeting to another toolkit, when the accumulated code of many years wasn’t as careful as it could have been with separation of UI logic from the rest, is no small software engineering challenge.
But we at upstream have our strategy for accomplishing this, which you may watch unfold.
We could use help with some tasks, and I really wish some of you smart and highly motivated people were not averse to volunteering some help.
Maybe the rearchitecting could even make the GTK option easier too.
I am not expert in the differences among UI toolkits. I am expert in what exists in this C++ source tree now. I have never retargeted a big app to another toolkit in my life before, but I have better ideas for accomplishing it in this case than anyone else’s that I know of. It it far easier said than done.
I suppose merging updates from Audacity regularly would be the most realistic path towards this. That has lots of implications, for example, we may decide to hold off on automated code formatting to facilitate that. We need to have a discussion how we're going to handle merging code from Audacity. So far we've mostly been focused on getting the build infrastructure working well and rebranding. I would like the first Tenacity release to be up to date with the latest Audacity stable release.
We could use help with some tasks, and I really wish some of you smart and highly motivated people were not averse to volunteering some help.
I don't think anyone here is going to sign Muse Group's CLA.
As for GTK versus Qt, I would go with Qt. Even if GTK4 has better Windows and macOS support, it doesn't have nearly as much labor being put into Windows and macOS support as Qt does.
I suppose merging updates from Audacity regularly would be the most realistic path towards this. That has lots of implications, for example, we may decide to hold off on automated code formatting to facilitate that. We need to have a discussion how we're going to handle merging code from Audacity. So far we've mostly been focused on getting the build infrastructure working well and rebranding. I would like the first Tenacity release to be up to date with the latest Audacity stable release.
We could use help with some tasks, and I really wish some of you smart and highly motivated people were not averse to volunteering some help.
I don't think anyone here is going to sign Muse Group's CLA.
Well maybe someone watching what we do might at least have helpful suggestions in code review.
Friends, you all forked too early.
Honestly, @Paul-Licameli, don’t take it personally, but you don’t get to call the shots on whatever other people do in their free time with free software, which gives them the freedom to fork and else. I have seen this before — at LibreOffice, there was a certain Rob Weir who was paid to troll over our project and promote the always-failing Apache OpenOffice project, which is still a zombie. We, too, were told through implications that we fractured the community, and that we forked unnecessarily or refused to collaborate (ha!). And time served Weir right. Please don’t be like him.
(Also: it’s pretty rich for Audacity people to ask for contributions, when the actions of your parent group are precisely what drove people away.)
(Also, n.º 2: In case it isn’t obvious, I speak for myself here, not for the project.)
Friends, you all forked too early.
Honestly, @Paul-Licameli, don’t take it personally, but you don’t get to call the shots on whatever other people do in their free time with free software, which gives them the freedom to fork and else. I have seen this before — at LibreOffice, there was a certain Rob Weir who was paid to troll over our project and promote the always-failing Apache OpenOffice project, which is still a zombie. We, too, were told through implications that we fractured the community, and that we forked unnecessarily or refused to collaborate (ha!). And time served Weir right. Please don’t be like him.
I am not "calling" any shots, and I'm not taking any offense.
I express real regret that we won't collaborate on this big challenge of delivering to the user community an Audacity rebased onto a better UI toolkit. Collaboration could hasten the day that it happens.
I have my plans for doing it. I wish we could discuss more about it before the fact. In any event you will be free to read what I write after the fact. The source for Audacity remains available.
Friends, you all forked too early.
This is objectively correct. Not only is this made obvious by the fact that we had half-finished features as a result of not basing ourselves off a stable version and are trying to amend this through painful cherry-picks. I've said this before, but if the same group of people that gathered as a result of the controversy were put in some room together and begun to process this entire thing, we'd be better off. After all, this project was forked by one person, whereas me and the rest of us that are currently affiliated now got entangled later on, so...
We could use help with some tasks, and I really wish some of you smart and highly motivated people were not averse to volunteering some help.
Maybe the rearchitecting could even make the GTK option easier too.
The deal here is that this is actually about donating, rather than volunteering. Personally, I have "donated" rights to some of my source code before to Haiku, Inc., and I (as well as other contributors) have coordinated/communicated with projects like wxWidgets over the past month, which is exactly where both Audacity and Tenacity wins.
I think that I speak for most, if not all, when I say that the problem here is that entrusting a private entity with a non-transparent business model (how the hell do you make money off Audacity, seriously?! Is it the Nyquist plugins, I'm seriously dying to know.) with multiple communication breakdowns and at least one person fully issuing a very indirect threat towards another community member and multiple tone-deaf decisions that evolved into huge communications breakdowns. I don't trust this. I fully respect you and your work, by name, but I just don't trust that. I'm not entitled to know, but there's a difference being in a neutral state of ignorance and in a fearful state of ignorance. That's why we are here. Although I don't think that people should be as hostile to you, personally, even with the conflict of interest, and that you should be free to express your opinion, they are afraid or even annoyed that you're derailing our efforts, because of the same reason why they are here.
If you make portions of Audacity that other projects can use as well available, say, some Nyquist backend or something like that, "l'art pour l'art" instead of carrying patches from 2009 that could've as well been upstreamed with minimal effort, I would be much less averse to contributing to something that you can also "coincidentally make money out of", but here I am, not even knowing what is up with the whole "We can just relicense if we deem some changes as too small". I don't even know who your lawyers are. As said to me in private by another contributor, you (as in MuseGroup) are much more liable than we are, but considering that there have been so many situations that scream "I am unreliable", that's not good enough of a guarantee for me to show full trust.
But still, if you need help with some tasks, the first step for basically any of us to start working with you for free and on a voluntary basis would be making whatever the task is be based on something that's also open and free and not just like "you can just have this thing and do whatever with it". L'art pour l'art. The fact that you're extracting all these libraries and separating different parts of Audacity could be made into a positive step towards that direction if you want it to be, I guess. We've also gone to extreme lengths in order to be transparent and establish proper governance, which has taken up a LOT of our time, and not repeat the same mistakes, so, some steps towards that direction would be great as well. Generally speaking, all of that is none of our business, but when you're asking any member of the community to do something like this, well, this is where the entitlement sort of strikes. I'm just trying to be super clear about all of this in good faith. I don't think that continuing this discussion for a lot longer is the right thing to do here, because it does derail the conversation, so I'll mark this reply and further replies as off-topic (simply for the sake of preventing our conversation about Qt/GTK from getting derailed, and not because I don't see it as welcome).
To get back to the topic of Qt/GTK with a little summary, am I correct with the assumption that a complete GUI rewrite would be for the best? As in, start separating GUI from backend before actually switching to a different library. That'd be best in the long run, I think, but also a huge effort, and therefore wasted work if upstream does the same. That correct?
Continuing that line, perhaps different flavours could be a solution to the qt/gtk debate, i.e. distributing a qt and a gtk version (and maybe a wxWidgets version too) - in any case, that's not going to be in the near future I think, and focussing on the GUI separation would be for the best for now.
Honestly, I don't think we care too much about compatibility with upstream. The only thing I'd care about personally is merging unfinished/half-finished features as seen in #515 and audio engine stuff/bug fixes/overflows/minor stuff.
There was another person working on Tenacity that wanted to help bring the application to native GTK too. If we were all to combine our efforts, we'd probably be able to achieve something similar to Transmission, which has multiple frontends written for it that are treated equally.
Tell me more about Transmission. It may be an instructive example.
It seems like a failure of cross-platform toolkits, if projects have to end up inventing their own cross-cross-platform meta-toolkits as perhaps they did there.
To get back to the topic of Qt/GTK with a little summary, am I correct with the assumption that a complete GUI rewrite would be for the best? As in, start separating GUI from backend before actually switching to a different library. That'd be best in the long run, I think, but also a huge effort, and therefore wasted work if upstream does the same. That correct?
Continuing that line, perhaps different flavours could be a solution to the qt/gtk debate, i.e. distributing a qt and a gtk version (and maybe a wxWidgets version too) - in any case, that's not going to be in the near future I think, and focussing on the GUI separation would be for the best for now.
I have been telling people to embrace the paradox... To figure out how to use Qt, first figure out how NOT to use Qt, in as much of the program as we can.
Tell me more about Transmission. It may be an instructive example.
I think transmission daemon provides a RPC API, and then there's a libtransmission that helps dealing with that and there are multiple GUI implementations that just use libtransmission to talk with the daemon. So there's native Mac Cocoa GUI, GTK GUI, Qt GUI, a command line interface AND a web interface.
On top of the daemon, there's also a bunch of third party versions that talk with it over the HTTP RPC API as well.
This fits well for transmission, as it wants to run in the background to download and share your favorite GNU/Linux distribution images. I don't think that's quite what we really have in mind here for tenacity, as it's a heavily enforced separation of concerns via RPC, not just via code structure. But it could be a shared base library and then different GUI implementations on top.
It seems like a failure of cross-platform toolkits, if projects have to end up inventing their own cross-cross-platform meta-toolkits as perhaps they did there.
It would be good to know where Audacity is planning to go in these regards too. Use wxWidgets for the next decade still? Still to be planned what to do?
I certainly would not try to follow an approach similar to transmission, as long as the manpower of this project is insufficient to handle the complexity. It would need active maintainers for each UI port. (Sorry for not bringing a solution to the table)
The GTK project did the opposite - it started catering more to other desktops than GNOME by getting the adwaita theme out of there, so that the GNOME releases changing things every 6 months or so wouldn't affect non-GNOME apps default look because a GTK point release was previously tweaking the theme to coincide some GNOME release. The linked post is full of misinformed opinions and conclusions really, the counter post would be https://blogs.gnome.org/alatiera/2021/09/18/the-truth-they-are-not-telling-you-about-themes/
However, as long as we don't use libadwaita, none of this should be of a concern really, other than perhaps getting desktop dark mode detection and such better, for more reliable automatic light vs dark theming.
other than perhaps getting desktop dark mode detection and such better, for more reliable automatic light vs dark theming.
Just a note, this is still perfectly possible without libadwaita - you'll just need to do the DBus handling yourself.
Looks like it's unmaintained now https://github.com/AudMonkey/AudMonkey/commit/e92b0b85986d51e40fcccb41fec61bd261fc52e6.
I think that GTK4 might be the best; QT has some accessibility issues on Linux, at least, as well as Windows. I'd like QT better if they were more FOSS-friendly. I think GTK3 has the best accessibility, though I'm not certain (I'm pretty sure GTK4 works as well but would need a test app).
GTK4 has good accessibility, and in my experience it's easier to make an accessible app with it than in GTK3.