libretro / RetroArch

Cross-platform, sophisticated frontend for the libretro API. Licensed GPLv3.
http://www.libretro.com
GNU General Public License v3.0
10.11k stars 1.82k forks source link

Switch to Qt6 #16913

Open EoceneMiacid opened 1 month ago

EoceneMiacid commented 1 month ago

I realize most RetroArch users (especially those on Windows) couldn't possibly care less what goes on under the hood, as long as they can run it and play their games.

The problem on Linux, however, is that we like to install software via package managers. And because RetroArch is built using Qt5, this means we have to have that installed too, alongside any dependencies that requires.

This complicates a bunch of things - for example potential conflicts between platform themes, not to mention a whole lot of disk space wasted on libraries - and additional problems in regards to software development.

Qt6 has been out for years now, and many well-maintained apps transitioned to it. Except RetroArch.

So, if RetroArch could do this too, we can finally liberate ourselves from the need to have it installed.

Thanks for considering.

hizzlekizzle commented 1 month ago

Unfortunately, the guy who wrote and maintained the Qt5 menu is no longer around, but if someone would care to help with that transition, we would welcome the PRs.

keithbowes commented 3 weeks ago

I realize most RetroArch users (especially those on Windows) couldn't possibly care less what goes on under the hood, as long as they can run it and play their games.

The problem on Linux, however, is that we like to install software via package managers.

We do? I thought we liked to compile things ourselves: ./configure --prefix=$HOME/.local --disable-qt && make && make install

I'm a bit surprised that people actually use the Qt frontend. There's an old GTK 2 frontend that works fairly well (if you don't mind using GTK 2 and it writing obsolete settings to your config file), but the builtin Qt frontend is so slow that it's unusable.

And because RetroArch is built using Qt5, this means we have to have that installed too, alongside any dependencies that requires.

I didn't realize that was an issue. I thought the reason that there was such work in migrating to GTK 3 and Qt 5 was so that we could finally ditch X, not because there was an issue with having multiple versions of a library installed. I certainly don't mind having GTK 4 and Qt 6 installed beside GTK 3 and Qt 5 (any more than I mind having multiple versions of Lua). I don't know much about the Qt 5/6 situation (I know Chromium has both Qt 5 and Qt 6 "shims", and it decides which to use at program start), but it seems that GTK 3 is here to stay (projects that were quick to migrate from GTK 2 to GTK 3 seem to have no interest in going to GTK 4; heck, GIMP hasn't even been able to deliver a stable version using GTK 3 yet, though from what I understand, migrating to new versions of Qt is much easier than migrating to new versions of GTK: the GTK developers seem to get some kind of sadistic joy in making people rewrite their UIs for every new GTK version). By comparison of Chromium having shims for Qt 5 and Qt 6, Firefox hasn't bothered in even starting to move to GTK 4 (to quote one developer, "There's no gain to port Firefox to Gtk 4.0 - it does not have any benefit but adds more problems.").

v-fox commented 3 weeks ago

heck, GIMP hasn't even been able to deliver a stable version using GTK 3 yet, though from what I understand, migrating to new versions of Qt is much easier than migrating to new versions of GTK: the GTK developers seem to get some kind of sadistic joy in making people rewrite their UIs for every new GTK version

It's true… buuut the flip side of that is Qt being horribly bloated and you still get same pain if they deprecate some core old API, like they did with WebKit. So both GTK and Qt ways are competitions in being annoying.

I certainly don't mind having GTK 4 and Qt 6 installed beside GTK 3 and Qt 5 (any more than I mind having multiple versions of Lua)

That's only because you're used to bloat and don't appreciate Lua for being the most slim yet still practical framework today compared to those monsters that also have entire tree of dependencies from their dependencies with their dependencies ("modern and fashionable" Rust and Go has gone full-nutso C#/.NET-style with this and just infuse every 100 KB app with 30 MB of entire OS' worth of statically linked deps with hardcoded versions while things like Electron infuse every app with entire instance of chromium browser to render a single semi-blank 2D page with some html-tags). And don't get me started on their compilation in Gentoo, Arch or rpm-package build-farm.

We do? I thought we liked to compile things ourselves: ./configure --prefix=$HOME/.local --disable-qt && make && make install

I guess I'll do that for my package too. Just like with PPSSPP's frontends (you should not compile it with abandoned Qt either).