Linux Pale Moon with Qt toolkit

[jarsealer]

Is it possible to make Pale Moon use the Qt toolkit instead of GTK? The GTK build looks a little out of place on DEs using Qt like Plasma.

[Basilisk-Dev]

It is not possible at the moment. Our code has no QT toolkit support at this time.

That being said, I have been experimenting with this in private for maybe 2-3 months and have a proof of concept that does show the GUI and renders sites, however it is extremely buggy and not feature complete. I wasn't sure if it was something people would want so I hadn't planned on submitting a PR or anything.

One example of such a bug - you can see it shows the help menu even though I already clicked "About Basilisk". It should have disappeared.

Please see the screenshot.

[Moonchild]

I think it would be more fruitful to pursue that SDL effort than writing a third linux widget code sub and having to maintain it, only to end up being asked for more/more versions.

[athenian200]

I mean, depends on the definition of "possible."

Like, if you mean could it be done in theory? Yes, not only has Basilisk-Dev been tinkering in private, but Mozilla did once support Qt a long time ago, they just removed it and standardized on GTK. So yeah... it could use Qt if we really wanted it to. Do we have an implementation ready? Well, not really. It isn't a feature we've seen a lot of call for.

I think for the foreseeable future, we are likely tied to GTK3. Supporting that is going to be our lifeline that gets us through the deprecation of GTK2 on mainstream Linux, and it is still at the core of some major Linux desktops like MATE and Cinnamon. If our goal really were supporting modern GNOME, I'd be considering trying to do GTK4... but I feel like until/unless MATE, XFCE, and Cinnamon go GTK4, that transition would be premature since currently GNOME is the only major desktop using GTK4.

As for Qt? I feel like that isn't really worth considering unless we find the majority of our Linux users are on KDE Plasma or something instead of a GNOME fork, and I'm suspecting we have more people on Cinnamon, XFCE, MATE, and even GNOME itself than anything else, though I haven't taken polls.

[mittorn]

There was qt code in gecko tree and there is patchset, adding qt5 support to gecko again:
https://github.com/sailfishos/gecko-dev/tree/master/rpm
It's likely to be possible to restore it
But do we need heavy qt5 only to open window with it?
Also, xulrunner-qt5-based browser (it's default in sailfishos) constanly OOMs on my 3GB RAM phone while SDL2 Basilisk port works stable

[jarsealer]

Seems like GUI in Linux is complicated, but if SDL is easier to support then I guess it's better than depending upon the goodwill of companies not deprecating their tool-kit for newer versions. I don't know what SDL really looks like however, from the few searches I did it looks like it's used in video games and emulators.

[Basilisk-Dev]

Seems like GUI in Linux is complicated, but if SDL is easier to support then I guess it's better than depending upon the goodwill of companies not deprecating their tool-kit for newer versions. I don't know what SDL really looks like however, from the few searches I did it looks like it's used in video games and emulators.

That is the main use of SDL yes. IMO SDL isn't a good choice for actual desktop applications, but it supports basically everything so I understand why we might want it to ease in porting our codebase to a new OS. Android, Nintendo Switch, PSP, OS/2, Haiku, basically anything you can think of from the last 20+ years has some form of SDL support.

[frostknight]

If I was choosing toolkits, I would use FLTK.

[Drugwash]

I'm suspecting we have more people on Cinnamon, XFCE, MATE, and even GNOME itself than anything else [...]

For what it's worth I personally always had an attraction towards KDE and their Qt, but I'm talking about older versions not Plasma. In fact, if I were to choose another OS now I'd go for Q4OS and their Trinity (TDE) desktop based on KDE3.

A couple years ago out of desperation I installed the 32bit version of Q4OS v4-something on a friend's machine, an ancient AMD Barton 32bit SSE-only relic, and since their Konqueror didn't sit well with me I searched and installed an unofficial 32bit SSE Pale Moon on that machine. It worked fine considering the very limited resources (3GB RAM).

Me, as I'm running Cinnamon in Linux Mint 19 I do have a few KDE/Qt5 applications installed, and they're working reasonably well. Thanks to Rob Savoury's backports I even have Qt6 installed, and I did build myself the Qt6 versions of Double Commander 1.3 and qBittorrent 4.6.7. Even installed the Kvantum engine for Qt5 and Qt6 theming - not perfect but it's working. So GTK and Qt can mix, willingly (and maybe with a sprinkle of luck).

The GTK build looks a little out of place on DEs using Qt like Plasma.

Maybe I'm wrong but I always saw the KDE community as somehow having set itself apart from the others. They tend to keep to themselves. However, I believe Pale Moon could gain a place in that community if it had a stable Qt port that would fit much better visually. Maybe Qt5 for larger compatibility, with a prospect for Qt6 too at some point.

Anyway, that's just my thoughts and nothing more, an opinion from the users' side. Right now I'm happy I can build and run both Gtk2 and Gtk3 versions of Pale Moon on my antiquated system.

[Basilisk-Dev]

Me, as I'm running Cinnamon in Linux Mint 19 I do have a few KDE/Qt5 applications installed, and they're working reasonably well. Thanks to Rob Savoury's backports I even have Qt6 installed, and I did build myself the Qt6 versions of Double Commander 1.3 and qBittorrent 4.6.7. Even installed the Kvantum engine for Qt5 and Qt6 theming - not perfect but it's working. So GTK and Qt can mix, willingly (and maybe with a sprinkle of luck).

Agreed. Users can run QT applications on GTK based desktops and GTK based applications on QT desktops. Generally most desktops will make the applications in the other toolkit look native in terms of the theme as well. Theargument that we'd only consider QT if we found a large number of users to be using KDE is a poor argument for this reason, although there are other reasons that are more valid to stick with what we have for now. GTK4 would be a terrible choice.

Do we have an implementation ready? Well, not really.

I posted a screenshot of a mostly working QT6 implementation.

[jarsealer]

Generally most desktops will make the applications in the other toolkit look native in terms of the theme as well.

Not a huge deal but, I use the Breeze Dark theme in KDE, PM does use the breeze icons but the default theme is white, not dark. Same with Basilisk.

[Drugwash]

GTK4 would be a terrible choice.

Couldn't agree more! I'd even refrain from uttering that dreaded word. Ugh!

Would your Qt6 code be available publicly for a test? I'd like to play around with it when I have some time. Unless it requires libraries that my system can't provide such as GLib 2.28+ and the likes, or too new building tools.

[Basilisk-Dev]

Not a huge deal but, I use the Breeze Dark theme in KDE, PM does use the breeze icons but the default theme is white, not dark. Same with Basilisk.

I think there might be some setting you have to change, been a while since I used KDE.

Would your Qt6 code be available publicly for a test? I'd like to play around with it when I have some time. Unless it requires libraries that my system can't provide such as GLib 2.28+ and the likes, or too new building tools.

https://repo.palemoon.org/Basilisk-Dev/ ... ranch/qt6/

Please note that it is currently extremely buggy and is not suitable for every day use, but it does work from the standpoint that the browser launches and can browse sites.

[Drugwash]

Please note that it is currently extremely buggy and is not suitable for every day use [...]

Thank you. Don't worry, I have Pale Moon for daily usage. Just looking for something to take me away from the daily routine.

EDIT: Well, after two hours of 100% CPU usage the build process ended with 2 errors. Could it be due to missing .mozconfig? Found none in the repo, and dunno what to put in one anyway if I were to create it from scratch as Qt6 is not an official option. Is there a generic template somewhere for Basilisk?

Code: Select all

119:28.71 make[4]: *** [/<src path>/Basilisk-Qt6/config/recurse.mk:71: js/src/target] Error 2
119:28.71 make[3]: *** [/<src path>/Basilisk-Qt6/config/recurse.mk:33: compile] Error 2
119:28.71 make[2]: *** [/<src path>/Basilisk-Qt6/config/rules.mk:493: default] Error 2
119:28.71 make[1]: *** [/<src path>/Basilisk-Qt6/client.mk:413: realbuild] Error 2
119:28.71 make: *** [client.mk:169: build] Error 2
119:28.71 563 compiler warnings present.
119:30.14 Failed to parse ccache stats output: stats zero time                     Sat Aug 10 12:24:37 2024

I wonder what's with that bogus date ? We're not in August as far as I know, and definitely not in 2024! (And yes, the computer date time itself is accurate)

BTW, I get the same ccache failure everytime when building Pale Moon but I have no idea what's it about and how to fix if possible

[athenian200]

Agreed. Users can run QT applications on GTK based desktops and GTK based applications on QT desktops. Generally most desktops will make the applications in the other toolkit look native in terms of the theme as well. Theargument that we'd only consider QT if we found a large number of users to be using KDE is a poor argument for this reason, although there are other reasons that are more valid to stick with what we have for now. GTK4 would be a terrible choice.

Yeah, I'm just saying I'm not sure about embracing Qt solely because GTK seems to have become a worse option, especially if it turns out most users will be in GTK4 environments in 5 years anyway. That would mean we'd be bound by some of Mutter's constraints even if we use Qt? I wasn't really arguing for anything yet other than maybe a poll seeing what environment most users are on, what direction those environments are moving in, and figuring out what can realistically be done with the foundation we would have to build on. My concern is mostly that I don't want us to be targeting solely alt-Linux and old computers... remain compatible, yes, but not plant our flag fully in that space and give up on modern Linux entirely. And sometimes it feels like there are a lot of forces pulling us in the wrong direction on that front and lulling people into a false sense of security, which is why all these toolkit-related issues are sticking in my craw all of a sudden and making me uneasy.

I posted a screenshot of a mostly working QT6 implementation.

Yes, but you also said it was experimental and not ready, right? Usually when I say something is experimental or mostly working, I don't want people to count on it being available or a viable option yet. If I claimed it were ready or practically ready, that might put pressure on you to finish it, or prompt early acceptance/rejection of the idea based on an awkward alpha/bata impression, when you were really just playing around with it to see how it looks. Sorry if it seemed like I was dismissing your work, I didn't mean for it to come across like that.

That said, if you are now saying your implementation of Qt is mostly finished, you're offering it up for people to play with, and it only has a few bugs left to be ironed out... then that does change things considerably because now the Qt work has already been done, and the bar becomes a lot lower... if it works well enough in most environments and Qt6 is scheduled to outlive GTK3 in terms of security updates, it becomes worth considering solely because it means we don't have to do GTK4... which I agree is not a good optio, but it could be "made to work" (probably would need custom widgets, some careful overrides to widgets that do exist in GTK4, and probably a lot of extra work since I wouldn't want to pull in libadwaita) and has some advantages like better integration with glib, which we rely on for event loops and such on Linux. Still, Qt also has some advantages over GTK, like better KDE integration, all or most of the widgets we need, and not needing as much custom code to get something that looks okay without libadwaita (which is the only realistic way we can do GTK4 anyway, the non-libadwaita path, which is of course the harder one).

I mean, I think it just comes down to the fact that any attempt to support modern mainstream Linux (especially 5 years from now) is going to involve some unhappy compromises no matter what we do. Modern Linux isn't the friendliest to our direction as a project, but I don't really want to ignore it completely and just build a wall around ourselves out of XLibre and GTK forks either... you know what I mean? Not that we can't keep on supporting those older technologies, but there's a difference between being friendly to alt-Linux and other Unix-like OSes... and falling so far behind that we are totally relegated to that corner and unable to run on modern mainstream Linux without the user installing weird RPMs from questionable sources or compiling old stuff themselves in 5 or 6 years.

[Moonchild]

What I worry about with Qt is that it has fairly quick turnover/deprecation; there tend to be a lot of breaking changes between Qt versions. While that's fine with native UI programs, it becomes more problematic for something as large and complex as XUL interaction in our code.

[frostknight]

heargument that we'd only consider QT if we found a large number of users to be using KDE is a poor argument for this reason, although there are other reasons that are more valid to stick with what we have for now. GTK4 would be a terrible choice.

What about FLTK?
https://www.fltk.org/

It has so few dependencies and that is why I approve of such an idea.

[Basilisk-Dev]

What I worry about with Qt is that it has fairly quick turnover/deprecation; there tend to be a lot of breaking changes between Qt versions. While that's fine with native UI programs, it becomes more problematic for something as large and complex as XUL interaction in our code.

I do agree with that concern to a certain degree. That was definitely the case with older QT versions, but is not as much of a concern with newer ones.

QT5 came out in 2012 and still gets support and occasional updates in 2026. QT6 came out in 2020 so in theory assuming it gets the 14 years of support that QT5 has, that should get us to at least 2034 in terms of having a fully supported GUI toolkit that works with modern *nix. On newer QT versions, porting to a new QT version is much more trivial than porting between GTK releases as well, porting from QT5 to QT6 for example is fairly trivial.

What about FLTK?
https://www.fltk.org/

It has so few dependencies and that is why I approve of such an idea.

I looked into FLTK as one of the options to try out before settling on trying out QT6. Personally I'd prefer something like FLTK or FOX but they are very minimal and would need a lot more work to work with our codebase. We'd be custom implementing a lot of GUI widgets that GTK or QT already provide.

I mean, I think it just comes down to the fact that any attempt to support modern mainstream Linux (especially 5 years from now) is going to involve some unhappy compromises no matter what we do. Modern Linux isn't the friendliest to our direction as a project, but I don't really want to ignore it completely and just build a wall around ourselves out of XLibre and GTK forks either... you know what I mean?

Definitely agreed. That's why I did the EGL port and have looked into the feasibility of porting to QT6. I think we should start preparing for the future now so that we are prepared because eventually we are going to stop working with newer *nix because of all this stuff, especially newer Linux.

[athenian200]

What I worry about with Qt is that it has fairly quick turnover/deprecation; there tend to be a lot of breaking changes between Qt versions. While that's fine with native UI programs, it becomes more problematic for something as large and complex as XUL interaction in our code.

That is my fear as well, and why I was considering biting the bullet and doing GTK4 in a few years, even though it would be twice to three times as much work as Basilisk-Dev's Qt port for results that are not guaranteed to be appreciated. If a lot of our users are indeed on XFCE, which is going GTK4... and GTK3 eventually stops getting security updates. Well, that's the situation where I would want to do that. Not because I like GTK4 or think it's a good option, but because doing nothing starts to have a price, and GTK3's main appeal is basically that it gets security updates and distros are more likely to ship it, not that it's the best version of UXP on Linux in the opinion of most Linux users. If that changes, it becomes effectively worthless... not better for NPAPI, not good for old themes, and also unsupported upstream. Which would mean users would shift to GTK2 even more, and pull our Linux support even more firmly in the direction of alt-Linux and old machines. Which means GTK4 (or Qt, or SDL, or EFL, or whatever) would effectively have to take the place of GTK3 at that point.

But yeah, I feel like Qt changing too quickly is the biggest potential mark against it, because that means going out of the frying pan and into the fire. We ideally want the opposite of that... something that changes slower than GTK but is still focused on remaining compatible with XWayland long-term, if not Wayland directly. I really hope we never have to do a native Wayland port, and I know you don't like that idea either, but in all honesty, if I heard XWayland was going away and it was either do native Wayland or be relegated to distros that still ship custom forks of X11. I'd be strongly considering Wayland. But I would much rather stay on XWayland as long as possible, not just out of laziness, but because I genuinely don't know where mainstream Linux will be in 5 or 6 years. Maybe it will be on Wayland, maybe it will still be split between X11 and Wayland with XWayland as a more permanent bridge than people would have liked, or maybe a third new thing will start being pushed and all the people who ported to native Wayland will turn out to have essentially wasted their time.

Though it's really hard to say which toolkit is better supported nowadays... KDE is supposedly becoming more popular, which could mean better long-term support for Qt versions in the future if more stuff is built on it. Linux is in an annoying state of flux right now... flux between GNOME and KDE, flux between X11 and Wayland, and it's hard to trust anything enough to commit to a direction.

[andyprough]

Though it's really hard to say which toolkit is better supported nowadays... KDE is supposedly becoming more popular, which could mean better long-term support for Qt versions in the future if more stuff is built on it. Linux is in an annoying state of flux right now... flux between GNOME and KDE, flux between X11 and Wayland, and it's hard to trust anything enough to commit to a direction.

I'm pretty sure most desktop GNU/Linux users use both GTK and QT packages already. It's pretty easy, just pull in a few dependency libraries, and you are up and running. So, focusing on one should not be seen as cutting out the other.

As far as your earlier concern about Xwayland disappearing, that's been discussed for many years but doesn't seem realistic. The world is full of odd bits of enterprise software that is never going to be ported to a new display protocol. As much as the Wayland developers would probably love to get rid of Xwayland, it just doesn't seem remotely possible in a time horizon less than multiple decades. I could be wrong, but I wouldn't make that my chief concern. If you wanted to port to Wayland, I would do it because of some advantage it would give you, not because of some threatened loss of Xwayland.

Just my 2 cents.