Platform Development • Re: Future of GTK2 and Pale Moon

Is any of that sensible? Or have you already considered these things and realized they would all fail? Just checking - I am one of those people that haven't used NPAPI plugins for many years, and have no need for them going forward. But I understand trying to help those that do rely on them.

Yeah, this makes sense. I do appreciate the advice. It is good to know that GTK3 does still support some of the functions needed, and I would probably have to look into this to see what error messages we get on distros where GTK2 isn't available, it has been a while since I checked on all this, and a lot of my assumptions were based on Bugzilla research which really only tells me what Mozilla thought, but their knowledge of the API may not have been the best because they were thinking in practical terms about deprecating something at the most rational time, not about digging into the API to see if they could save it.

I believe we already have plugin-host as a separate process for GTK3, if I'm not mistaken, and that's why we can run GTK2 plugins on the GTK3 version of the browser at all. The real sticking point is potentially having to ship a GTK2 runtime at all if distros don't offer it in their repos... licensing issues basically force our hand there. I don't think we'd need much of GTK2 to make plugins work, but we are basically in the situation where we build plugin-host against GTK2 so that loading plugins with GTK2 symbols in them doesn't cause issues. That part we have taken care of. The issue is more that we're not comfortable shipping a GTK2 runtime with the browser because the licensing on that library is not fully MPL compatible. If the user can somehow get ahold of GTK2, the plugins should always work.

We've actually long hoped users would port themes over to GTK3 and improve the look/feel now that the toolkit isn't changing as rapidly as it was early on (it's become the new stable release since GTK4 came out, and MATE actually looks half-decent with GTK3 because they are deliberately trying to mimic GNOME 2), but really the reason GTK2 has lasted as long as it has... is because most users just don't want GTK3, theme authors seem unwilling or unable to fix their themes for GTK3 environments, and thus GTK2 has remained primary because it's what users keep choosing rather than because we as developers would rather they use it. This is actually one of the reason why I have been a little anxious about users picking Linux over Windows lately. Because deep down, I know the Linux version is not in the best state for modern Linux, and it means more users relying on the version of our code that we'd rather they didn't, especially if they get advised by other longtime Linux users on the board to "get the GTK2 version" because it's the "good version" that works better with themes, and thus reinforcing the whole problem of themes not getting updated to work with GTK3.

The issue is that on distros where GTK2 isn't in the repos, but plugin-host was compiled with it available, most plugins would simply not work, I think, though possibly some still would. If someone wanted to compile Pale Moon on such a distro, they would, as things stand, have to disable NPAPI or hunt down and install GTK2 development headers themselves in a place where UXP can find them, so plugin-host can be built.

Another added wrinkle is that the version of glibc some plugins were compiled against isn't compatible with the glibc on modern Linux distros anyway, so even if GTK2 is available, they might not work. I mean, the Pipelight suggestion isn't coming out of nowhere. That said, the new project Basilisk-Dev mentioned to create open-source NPAPI plugins that can do what the old proprietary ones did is the kind of thing Linux/FOSS is a bit stronger on, and they definitely deserve a lot of credit for that.