Hi there. I was wondering if there would be any interest in having a filter in the Flathub website, and/or usable in software center apps, that would allow filtering apps by which GUI toolkit they have.
With the introduction of libadwaita and the fact that you can’t theme it*, just like libgranite, we are now in a situation where there are four GUI toolkits in use. Vanilla GTK, libgranite, libadwaita, and Qt. It would be useful to be able to filter out apps that will look and feel alien in your desktop environment, whatever it may be.
Software apps may be able to detect the “right thing” based on the session type in use. This is of course purely subjective and should be changeable by the user. GNOME probably wants libadwaita and vanilla GTK. Pantheon probably wants libgranite and vanilla GTK. KDE and LXQT want Qt, and I would say vanilla GTK too, but I’m not so sure anymore. Smaller GTK environments have the rawest deal because they don’t have big teams of influencing programmers pushing them as “platforms”; XFCE, Budgie, Cinnamon, MATE, etc should probably only seek vanilla GTK apps by default.
Electron and other GUI-toolkit-independent apps like Steam throw a huge wrench into everything, of course. Tooklit-wise, it’s GTK, but in practice, pretty much all of the main chrome will mismatch the rest of your desktop. The menus will match vanilla GTK, but that’s about it. I feel they should be shown by default because they comprise popular apps that users will expect to see by default even if they clash with the rest of the system. Further still… most Electron apps can be themed, albeit with third-party apps that support user Flatpak installations just fine, vs libadwaita and libgranite actively blocking customization. But I think they should be distinguished from the other GUI toolkits. So that’s five toolkits, actually.
I don’t know if games like GZDoom and emulators like DOSBox are relevant to this conversation since they don’t have any GUI.
Default toolkit filtering heuristics should be user-overrideable. If a user wants the potential to have a circus of mismatched apps, and can handle that sort of look-and-feel cacophony, more power to them. And additionally, if a user wants to avoid Electron at all costs, they should be able to do that.
* I would say “right now”, but GTK/GNOME developers have demolished their good faith over a long period of time by consistently claiming “we don’t have a theming API” but also doing absolutely nothing to fix that while most of them are part of a no-theming alliance.