Contributed 3rd Party Builds • Re: 32bit and gtk2 builds for Debian/Bookworm

Off-topic: I don't think we should drop GTK2 support or NPAPI even if Linux distros are dropping support for GTK2. More experienced users will always be able to compile their own GTK2 if they truly need the GTK2 UI or NPAPI plugins. Even then, when we inevitably in a few years have to switch to an RHEL9 based distro for builds, GTK2 is still available for that OS as well. Same with RHEL10.

It definitely does do things. I had to make a few small patches in UXP, but I am using a modified personal fork of the LightSpark Adobe Flash NPAPI plugin on LoongArch, an architecture which did not even exist until after NPAPI was deprecated. It does not require GTK 2 or 3 at all. It uses SDL2.

Off-topic: You make good points, Basilisk-Dev. Yeah, we would definitely keep NPAPI on non-Linux regardless (I think that's a settled question), but the RHEL10 support for GTK2 was kind of my concern here since I don't think they have GTK2 in the official repos. I was originally thinking of decoupling GTK2 from NPAPI at some point so that people don't have to disable it entirely to build on non-GTK2 systems, but a few years ago it seemed like there was no reason to do that given that all extant Linux NPAPI plugins were built against GTK2 and there were fears of user confusion if they tried to build NPAPI without GTK2 and most plugins were broken. LightSpark does seem like a good argument in favor of keeping NPAPI around on Linux. Granted, a non-GTK2 NPAPI build would support very few plugins, but it would still support some, as the protocol itself doesn't require it. Overall, I don't necessarily want to remove GTK2 (it really wouldn't simplify our code much because the GTK2 stuff is mostly off in its own directories), but I would prefer to minimize our dependency on it as much as possible, and maybe move official support to a different emphasis at some point because I don't think it will be easily accessible forever.