Browser Development • Re: Linux Pale Moon with Qt toolkit

Taking a step back and looking at the entirety of things here, the most sane solution would be something that is no longer toolkit dependent. I'm just not sure what that might mean for how the browser looks, or interacts with the system. If Linux remains hell-bent on trying to move in 8 directions at once and disagreeing with itself, then what are we supposed to do?

That's actually the conclusion I'm circling around as well. I have considered just giving up on system integration on Linux altogether and doing something like SDL, Winelib, custom stuff, etc... if they really do get rid of XWayland (though I am actually skeptical that will happen soon).

But yeah, the awkward truth is that the safest thing to target on the X11 side is probably plain old Xlib. That's pretty much going to be supported as long as XWayland or X11 are in any form, but toolkits are not as safe (especially not ones as complicated as GTK, which some distros apparently chose to preserve as a full-on older GNOME desktop that could be pulled in for years rather than just a toolkit!). As far as native Wayland... well, the alternative to toolkits is writing your own compositor on that platform, because Wayland provides nothing and essentially forces you to trust someone else's toolkits and compositors or write your own compositor (though if you do write your own, you get a lot more freedom than if you rely on someone else's).

And then, there's the options that have been hinted at strongly by the UXP dev community already. Qt and SDL. SDL, it's obvious that's not tied to Wayland or X11, it talks directly to graphics hardware and is typically used for games rather than browsers, but it can be made to work for our use case. Qt is an interesting one... because it has backends for X11, Wayland, and also EGLFS which means it can basically render its stuff directly to KMS/DRM if needed. Granted, that's less full-featured and designed for kiosks, but it means in theory Qt could survive some nightmare scenario where XOrg is too bitrotted to continue and the forks are tainted by associations average Linux devs are uneasy with, but everyone is unhappy and exhausted with Wayland devs not adding features people want to the point of wanting to give up. Enter Qt offering up their own compositor that isn't tied to anything but their own toolkit and doing what Mir failed to do. Which really makes it interesting that Fedora is elevating their KDE spin to the front page... almost like an insurance policy is being signaled in case Wayland and/or GNOME fails, so they can pivot RHEL to KDE and Qt if needed. But needless to say, it seems like Qt is a lot better prepared for a future where Wayland doesn't succeed than GTK/GNOME is at this point.

But yeah, overall it really is looking like we may want to keep that SDL port in our back pocket as a way to support modern Linux "just in case" they drop support for too many things at once, so we aren't left scrambling and/or trapped in the legacy bin.