Linux Pale Moon with Qt toolkit

[BenFenner]

Or should we stick with what we have, make GTK2 and 3 as good as we can, and for future-proofing do away with attempting to integrate with desktop environments and find a way forward that is widget-agnostic?

I'm not sure if what I'm about to say is related, but I think it is. One of Pale Moon's crowning achievements IMO is its ability to match the existing look & feel of the operating system/window manager it is installed on. This is a core UI tenet that so many applications (browsers included) have abandoned, much to my chagrin.

[solitude]

I genuinely wonder if our Linux users would be happy with Qt on X11? Like, I just assumed a lot of our users prefer GNOME forks and GTK3, and that eventually those desktops will move to GTK4 with a handwritten replacement for libadwaita and a ton of widget overrides.

It seems like at least on this thread, there's way more interest in Qt than in GTK4, Wine, or SDL?

I switched from XFCE to KDE Plasma (Wayland) a week or so ago, main reason was the lack of security with X11 since it's apparently insecure and the GUI isn't isolated. Other reason was the consistency and integration of Plasma, various theming options, and just the general appearance. I'm pretty happy with Plasma and it's use of Qt.

[Basilisk-Dev]

Someone will need to test QT with NPAPI plugins obviously. I don't think it will work. That being said NPAPI plugins don't work most of the time on Linux for me anyways without a bunch of hacky workarounds. I had lightspark working a few weeks ago but it started crashing for me so I have no working NPAPI plugin on this particular machine to test.

[Moonchild]

main reason was the lack of security with X11 since it's apparently insecure

X11 has been secure for decades. But ask a Wayland proponent and they will say it's insecure, because they want to marry system core tasks with a graphical environment in Wayland. Not sure who you've been listening to but that very premise makes Wayland actually less secure when looking at the real world where bugs exist.

[athenian200]

Someone will need to test QT with NPAPI plugins obviously. I don't think it will work. That being said NPAPI plugins don't work most of the time on Linux for me anyways without a bunch of hacky workarounds. I had lightspark working a few weeks ago but it started crashing for me so I have no working NPAPI plugin on this particular machine to test.

Off-topic:
The only way it might work is if plugin-container is built against GTK2. Doesn't matter so much what the browser itself is built against as long as plugin-container is built against the same thing as the plugin.

But yeah, overall it seems like NPAPI support in Linux is not reliable. I did actually get Java working perfectly without GTK2 at all. I wasn't really able to test Lightspark's ability to run on my GTK2-free NPAPI setup, though, because I couldn't get it to run even on normal unmodified Pale Moon with GTK2 available.

So the best plugin to test with NPAPI is the final version of Java that included the plugin. I think Netscape used to bundle Java ages ago, so that's probably among the original use cases for NPAPI, and why it's so resilient.

[Gemmaugr]

Not currently using a Linux distro (though that might change in the future), but I was wondering if the Qt mentioned is the same one that's using google chromium for QtWebEngine..?

Windows didn't stop being a viable platform for Pale Moon because of Microsoft's Webview component, GTK didn't stop working with Firefox because of WebkitGTK. What browser the toolkit embeds really has nothing to do with whether UXP can use it.

True enough. It is a separate part and not directly relevant to all workings of Qt. It is only a fourth or fifth degree (out of six, depending on how you count) google encounter, so to speak.

[athenian200]

Off-topic:
Oh, and I was looking into the licensing on XWayland...

While we cannot bundle GTK because of viral GPL licensing. It turns out XWayland is mostly MIT and BSD licensed, with no copyleft obligations whatsoever. Which means if Linux distros did stop shipping XWayland, we could bundle it, and it's apparently not much more expensive to bundle than something like Cairo or Angle. Granted, all the sources I can find say that most distros, even fast ones like Fedora and Arch, really want to keep XWayland. But apparently if they ever did get rid of it, every app that relies on it could just start bundling XWayland and it would still work with minimal maintenance.

So that means X11-on-Wayland is likely to remain a valid way of doing things, and it's not as out of our hands as the toolkit situation. It probably seems counterintuitive or weird that we can ship a whole X server that runs as a Wayland client with less licensing issues than GTK2, but that's apparently the reality.

This means we may have to worry about toolkits, but I can pretty much guarantee we never have to go Wayland even if the distros lose their minds and force apps to bundle XWayland.

[Basilisk-Dev]

While we cannot bundle GTK because of viral GPL licensing.

Off-topic:
GTK is under LGPL not GPL. According to the terms of that license we can bundle GTK as long as a user is able to replace our GTK library with their own (basically for us that just means don’t statically link it so they can swap out the library file with their own).

That is why Mozilla can bundle GTK in their Flatpak and AppImages without being forced to relicense the whole codebase under the GPL. Because GTK is not under the GPL to begin with.

[jobbautista9]

I have no working NPAPI plugin on this particular machine to test.

You could try compiling this patched NPAPI plugin for VLC 3.x, but it's been a long while since I've last successfully built it: https://repo.palemoon.org/jobbautista9/npapi-vlc

[JayByrd]

main reason was the lack of security with X11 since it's apparently insecure

X11 has been secure for decades. But ask a Wayland proponent and they will say it's insecure, ...

Exactly. As Patrick Volkerding pointed out recently, if the Xorg-server were as insecure as the Wayland proponents claim, you'd think there would be security catastrophes happening regularly, as the hackers went after all that Xorg/X11 low-hanging fruit! Yet this never seems to actually happen...

In fact, as with any "mature" code-base so complex, (some might call it "spaghetti code,") there are bound to be "insecurities" discovered. Ever since I personally started following the CVEs for Xorg-sever almost a decade ago, all the vulnerabilities have been disclosed by white-hat security research, and freedesktop.org releases updates to patch the flawed code.

In any event, I myself don't see Wayland "taking over," no matter how hard IBM/Red Hat or anyone else tries to push it...

Just my two cents...

[athenian200]

In any event, I myself don't see Wayland "taking over," no matter how hard IBM/Red Hat or anyone else tries to push it...

I mean, it could take over as the default on Linux. But there's a world of difference between Wayland as a default, and no X11 support.

In my view, in a world where Wayland "wins," XWayland is still needed, but over time becomes viewed in the same light as DOSBox or Wine... a compatibility layer for old programs, not something native to a modern Linux system. Probably due to security concerns related to application windows being able to see another application's position and what else is running. I mean, like I was saying, applications could, in theory, ship XWayland as an included dependency on systems that don't provide it by default, it just runs a little X Server as a client on Wayland, and then shows you the application in a window. This is not far off from what X was designed to do in the first place, and why with the right setup you can see remote X11 applications on, say, Windows and they look like they're running in their own window natively. It was basically designed so that you could use the X server with a system that doesn't run X natively and it looks seamless. Wayland just means X now has to work with Linux the same way it does Windows, classic Mac, or anything else that isn't using an X server as the native display. Plus, using XWayland means each application potentially gets its own X server and can't see other applications anyway, which still solves what Wayland advocates are complaining about mostly without breaking legacy support.

So, X11 may not be the future, but it's pretty hard to kill, if only because anything that needs it can just embed an X server cheaply, run the application on the X server, and then use some kind of native program to connect to the X server and show you the application running. Now you have an X11 application running while something else controls the display. It's that flexible and embeddable. Seriously. That's how people get Linux desktop applications running on Android when they're not supposed to... just get an X server running, use a remote X server viewer pointed at localhost, and suddenly you can see a normal desktop on your phone.

X wasn’t designed around assumptions about the underlying window system or hardware. That neutrality made it easy to run on systems where it wasn’t the native display stack. Probably lots of Unix vendors in the 1980s had their own proprietary display solutions and X was a protocol that was more "neutral" and could allow applications to work on anything without assumptions about who has control of the display or how the underlying hardware/OS works. That ironically makes it perfect for an environment where Linux is on Wayland, Windows is Win32, Mac is Quartz/Cocoa, and stuff like Solaris or BSD is still dependent on X11. All of them can speak X and run an X server. Windows has XMing, Mac has XQuartz, Linux has XWayland. Mir even had XMir. So basically, the problem with trying to kill X11... is that anything you try to replace it with, can always create something that talks to an X server and shows you what it's doing, on the new thing you replaced X with. And the more different things you create, the more X11 backends for different things you create, until X11 is the only thing those different things have in common, and it turns back into the centralized glue that holds everything together all over again. It's like a weird self-reinforcing cycle that works in favor of anything that targets X11.

[Moonchild]

Apologies for the tangent.

I'm not even sure if Wayland is in a state where this hard push for it is even sane. It's missing core functionalities for a GUI server, and in fact departs hard from providing a uniform implementation for GUI applications to talk to as it offloads much of the interactive implementation to the DEs. In my opinion that is a big step in the wrong direction; as it is now it's a very restrictive compositor-only thing that gets in the way of app interaction, and it's asking every application and DE maintainer to (re)implement things that should, logically, be part of the software sitting where Wayland sits.
In that light, you can actually see XWayland as a necessary component, here. Wayland basically splitting X-server up into two parts: one kernel-facing part (Wayland) and one UI-facing part (XWayland), where the latter implements a uniform interface Wayland should have provided but doesn't. In a way it's similar to the whole Pulse/ALSA deal: If you want to, you can talk to either as an application, where ALSA is more involved for the application because it's a lower level, and Pulse is ALSA+abstraction. The only difference is that Wayland goes in the opposite direction, and trying to enforce individual implementations on the application/DE side while not bothering to implement a uniform abstraction.

To refer to something I saw recently, talking about X11 vs. Wayland:
DEs/window managers are supposed to sit on top of a common protocol stack that has a universal underlying system without deviations, and that is exactly what you get with X11. It's unambiguous and every piece of FOSS software running on top of that knows exactly what to expect; with it being as mature as it is, this is also not subject to rapid/breaking changes and everyone knows what is or isn't supported. There is no compromise between a protocol system that may have this or that in one DE/WM implementation but not being present in another. You don't have to choose which DE or WM you are targeting as an application. because you have X11, and only need to talk to X11.

X11 conforms also to any UNIX-like system as a uniform system. You can change the kernel, the userland, the entire baseline OS itself, but everything on top of that as seen from the software environment (actual applications) stays the same. You're not creating discrepancies that have to be (somehow) solved by application developers because they have already been solved in a uniform way in X11's protocol stack.

[dinosaur]

I must say that I would be very happy with a Qt version of PM...

GTK3 and GTK4 suck rocks, and I'm glad PM can still be built against GTK2, but Qt allows to use GTK2 themes as well (I have Qt4, Qt5 and Qt6 configured to do so on all my Linux boxes), and got the advantage of a C++ API (vs C for GTK), meaning an easier integration with C++ programs such as PM.

Of course, this would be all but an easy task to add Qt compatibility to PM code.

[andyprough]

I must say that I would be very happy with a Qt version of PM...

GTK3 and GTK4 suck rocks, and I'm glad PM can still be built against GTK2, but Qt allows to use GTK2 themes as well (I have Qt4, Qt5 and Qt6 configured to do so on all my Linux boxes), and got the advantage of a C++ API (vs C for GTK), meaning an easier integration with C++ programs such as PM.

Of course, this would be all but an easy task to add Qt compatibility to PM code.

Qt version of Pale Moon would be fine with me, I use plenty of applications with Qt toolkit, they work great.

Tell us more about how you have configured Qt4, Qt5 and Qt6 to use GTK2 themes? This could be a solution to one of Pale Moon's issues around GTK2.

[Drugwash]

Qt version of Pale Moon would be fine with me, I use plenty of applications with Qt toolkit, they work great.

Same here. I find that Qt/KDE applications seem to be built with a little more consideration than Gtk* applications, have more features, and don't crash that often (if ever). Sadly, this Qt experimental build of Pale Moon crashes badly (segfault). I know it's just a proof of concept but still. Maybe it's the toolkit? I used Clang as GCC failed to compile succesfully everytime I tried.

how you have configured Qt4, Qt5 and Qt6 to use GTK2 themes?

There is a configuration application that comes separately to the Qt suite. There is one for each Qt version: qtconfig-qt4, qt5ct, qt6ct.
These apps can select a common theming engine or a different one for each toolkit version, usually defaulting to DE's default. Through these apps there would be absolutely no difference between a Qt Pale Moon and native Gtk apps, on a Gtk system.

Screenshot from 2026-05-12 21-15-01_edit.png

I even built and installed a recent version of the Kvantum engine, which is available to all three Qt versions. Making themes for it is kinda difficult though; I couldn't find a SVG editor for my Mint 19 that could edit such a theme correctly, and the default ones are not at all to my liking (I strongly dislike dark themes).

Since we are back to the original Qt topic, my humble opinion is that Pale Moon could begin with a Qt5 port, a version that would be accessible to older systems too (I have Qt 5.9.5 as default here in Mint 19/Ubuntu 18.04),and for Qt6 could stick with Qt 6.2 which so far is the most that can be backported to such systems (6.2.13 is what I currently have installed).
I have no idea if a Qt4 port would be feasible and/or useful to users, maybe others could chime in on this.

[frostknight]

X11 has been secure for decades. But ask a Wayland proponent and they will say it's insecure, because they want to marry system core tasks with a graphical environment in Wayland. Not sure who you've been listening to but that very premise makes Wayland actually less secure when looking at the real world where bugs exist.

Off-topic:
Why am I not surprised that redhat devs created another half baked idea....

When I learned of systemd being a huge code base, I knew that it only makes sense if a code base is too huge at some point, no amount of eyes is enough to keep up with the fixes...

This was my first step to my detesting redhat... but the more time passes, the more I want them to go under.

Or... at the very least, go the way of BSD and do Things... RIGHT.

I mean FFS. It would be so much better if Redhat took the NetBSD or OpenBSD approach.

FreeBSD does have some slime though, can't say if that would make things better or not.

The more time passes, the more egomaniacs try to ruin anything good in this world. Billionaires, political groups, corporations... etc... you get the idea.

[dinosaur]

Tell us more about how you have configured Qt4, Qt5 and Qt6 to use GTK2 themes? This could be a solution to one of Pale Moon's issues around GTK2.

Via qtconfig (for Qt4), qt5ct and qt6ct. You might also need to install some additional packages, such as qt5-qtstyleplugins or qt6gtk2, and have a properly exported variable in your environment (for Qt5 at least): export QT_QPA_PLATFORMTHEME=qt5ct

See the screenshots below, taken from my typical Linux install, with Sawfish as the window manager and Crux as the GTK2 and Sawfish theme, and the gorgeous, pixel-perfect Helvetica (xorg 75 dpi) as the UI font.

qt4ct.png

qt5ct.png

qt6ct.png

I have no idea if a Qt4 port would be feasible and/or useful to users, maybe others could chime in on this.

Qt4 is the past, Qt5 is the present, Qt6 is the foreseeable future. I'd recommend not bothering with Qt4 and going for Qt5 (or maybe Qt6, but it might be a couple years "too soon" for many distros).

[Drugwash]

Qt4 is the past [...]

Technically true, but so is Gtk2 and it's still in use (and requested by a certain amount of people) despite distros retiring it.
I only mentioned Qt4 for completeness sake, and also knowing there are minimalist/lean/retro/etc distros out there that may benefit from such port. Dunno how difficult would be to squeeze in code for multiple versions of a certain toolkit but I know it's definitely possible. For a while I've been systematically building for myself from latest Github code all five flavors of Double Commander: Gtk2, Gtk3, Qt4, Qt5, and Qt6. All ready in ten minutes or less. Granted it's not as complex as a browser and it's written in FreePascal, but still.

Anyway, either Qt flavor of Pale Moon would be fine I guess. Hopefully this project gets to a working state soon.

[andyprough]

I only mentioned Qt4 for completeness sake, and also knowing there are minimalist/lean/retro/etc distros out there that may benefit from such port. Dunno how difficult would be to squeeze in code for multiple versions of a certain toolkit but I know it's definitely possible. For a while I've been systematically building for myself from latest Github code all five flavors of Double Commander: Gtk2, Gtk3, Qt4, Qt5, and Qt6. All ready in ten minutes or less. Granted it's not as complex as a browser and it's written in FreePascal, but still.

Anyway, either Qt flavor of Pale Moon would be fine I guess. Hopefully this project gets to a working state soon.

I would assume that this project would be Qt6, since one idea of such a project seems to be to start to future-proof things against additional radical toolkit changes by Gnome's gtk developers.

[Drugwash]

I would assume that this project would be Qt6 [...]

For now it is. Got no problems with that, on the contrary I wish to see it succeed. As long as I could build it myself for a reasonable amount of time in the future - considering the lack of official support for older machines/OS (which I do understand) - I'd gladly use it on a daily basis instead of the Gtk3 version I'm using now. But if a Qt5 variant could be added to the code reasonably easy then it might be of value at least for a certain segment of the userbase that are currently on a KDE system and would prefer Qt5 to Qt6 which might not be mature enough for their liking. And for me as well, as Qt6 is still a very recent addition to this system, and I'm not yet sure what issues may arise in time when mixing two or more Qt variants.There already is an annoying issue of the Qt file picker locking listView headers when switching from Qt5 to Qt6 applications and back, due to different ByteArray format between the two - issue that I had to make a lot of configuration changes in various applications for in order to work around it. This issue seems to have been fixed in Qt 6.3 and higher, but unfortunately right now there is no backport version higher than 6.2.13 available for Ubuntu Bionic and compatible systems, and Mr. Savoury still hasn't replied to my e-mail regarding implementing that particular commit to his backport.
So yeah, to me personally (and maybe others that don't have a voice here for any reason) a Qt5 port would be more stable and safer considering, but I'll take whatever I can get.