Linux Pale Moon with Qt toolkit

[Moonchild]

Linux is less an operating system, and more just a divided community of opinionated computer nerds that hate each other and can't agree on how to do anything, but ultimately are either too lazy or too practical to follow though on most of their fork threats

I should frame this, or something

But the main overarching problem I'm seeing here, stepping back from the overall details, is probably best summarized as:

• On the one hand, GIMP and other larger software packages have shown to the entire Linux user base that switching widget toolkit isn't quick or simple. And I have to agree with that; throughout our code base there's a pretty large amount of pretty specialized widget/toolkit code... The name doesn't do it justice, because it's halfway between UI and rendering engine.
• On the other hand, Liam's article clearly highlights that if you want to stay at the development forefront of Linux desktop, even if you use LTS versions, you are apparently expected to upgrade every two years. That would mean for us that this question would come up every time the new versions come out, so every 2 years.

In that light, does it even make sense to choose between GTK4, Qt, etc. or to offer alternatives being developed in parallel? ...when the overall community is not only divided, but in fact deliberately seems to be splintering into shards that by definition are going to be incompatible, diametrically opposed to every other one, requiring as many different approaches/toolkits... for something that 95% of our users don't even use?
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? We might be losing useful features here like drag&drop, snapping, clipboard handling, etc.
Or, if all we're doing anyway is trying to provide an integration layer, then why not run on Wine (since win32 isn't going away in the foreseeable future) and do away with native Linux builds? All things that roll around in my head reading this discussion.

[athenian200]

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? We might be losing useful features here like drag&drop, snapping, clipboard handling, etc.
Or, if all we're doing anyway is trying to provide an integration layer, then why not run on Wine (since win32 isn't going away in the foreseeable future) and do away with native Linux builds? All things that roll around in my head reading this discussion.

Like, I really think we shouldn't put more work into GTK2, at all... that's absolutely a dead-end, we are just keeping that around for NPAPI and no other reason in my opinion, maybe for self-builders who like tinkering with it. I feel like if anything we've let the idea persist too long that the GTK2 version is "the good version" (even though we know GTK2 is not a realistic option as time moves on). Distros are dropping it, applications have moved on to GTK3, even the forks of GNOME 2 that you'd think would have stayed on it grudgingly migrated to GTK3 for Wayland support and security updates. That much is known, GTK2's death certificate is the one variable I feel confident of in this whole mess. It might be worth putting more work into our GTK3 version and making that as good as it can be. It technically is not in the past, not yet, but GTK2 being dropped means it is next on the chopping block for sure (though we don't know when)... so we now currently support one dead toolkit, and one mature toolkit that is only getting critical security updates and used by semi-popular GNOME forks but not GNOME itself.

I think having a widget-agnostic fallback is important, simply because I don't think it would be good if we are at the mercy of distros dropping or not dropping what we depend on to be able to run on Linux. I doubt Linux users want that... they complain about wanting their system theme supported. But I think having a fallback that lets us run on Linux no matter what is a perfectly valid idea. At the very least, it would be an emergency brake we could pull in case mainstream distros drop GTK3 (or worse, XWayland, which I don't think is likely but some others think it could happen) so that we don't become something that only runs on Debian and its forks or whatever.

Though reading the room... I think most Linux users believe the future of anything that's not targeting GNOME specifically is Qt. It seems to be the option they trust most as a successor to GTK3 at the moment, there seems to be a frightening lack of interest in GTK4 outside of GNOME, the arguments are all about moving to GTK3... even though GTK3 is itself only getting critical security updates. All I know is, this doesn't seem like a healthy ecosystem, and something is very wrong if everyone is reacting to each major toolkit deprecation like a bomb is being dropped rather than a routine upgrade that might require some work but isn't unreasonable to deal with. Though from what I am hearing, Qt doesn't work like GTK, and the major versions don't break nearly as much these days (though a lot of people have bad memories of some earlier transitions). People do seem to keep recommending it for people that want long-term stability or anything enterprise-grade on Linux.

The closest analogy in the Windows world I can think of, and frankly I think you'd have to exaggerate it by a few orders of magnitude to really get a feel for it. GTK2 is emotionally (but not technically) similar to Windows XP and/or Windows 7 (depending on the era). It's pure nostalgia fuel with no practical value for targeting modern Linux that people just don't want to let go of for aesthetic reasons. GTK3 is sort of like Windows 10... something that people are grudgingly accepting because the old thing they loved is showing its age and they need something that they can make work well enough for their use cases. GTK4 is Windows 11... everyone is putting their foot down and dragging out their resistance as long as possible, even people who were happy with Windows 10. And emotions about this probably run higher in the Linux community than even in the Windows community, because Linux users are less rational and more idealistic, but also because there is more real, legitimate API breakage with newer GTK than there is with newer Windows.

[Moonchild]

Though reading the room... I think most Linux users believe the future of anything that's not targeting GNOME specifically is Qt. It seems to be the option they trust most as a successor to GTK3 at the moment

I'm not convinced it is.
There has always been this forced choice, you either used GNOME or you used KDE. If your application happened to use the other toolkit than your DE of choice was built on, then you were stuck either not using it or jumping through a ton of hoops having both on your system, making things really heavy. I don't know if that has changed recently, but "switching camps" just doesn't seem viable, because we'd gain one portion of users and lose another. Qt isn't a "successor", but rather a competitive sibling.

It might be worth putting more work into our GTK3 version and making that as good as it can be. It technically is not in the past, not yet

That's not the thing I read from various things on-line. Even in this thread it's clear that GTK3 is "in maintenance mode" basically meaning it's deprecated for use, and people "should migrate to gtk4" because the GNOME devs have made that choice. If they aren't supporting it, then who is? Nobody. So then that makes GTK3 a dead end as well. Wayland is just too big of a change to reasonably support for us. It fundamentally changes how we're supposed to talk to the ISO layer below us, and I just don't see that happening without having at least some foundation to build on.
It ultimately becomes a game of numbers: how much time and effort can we reasonably spend on this? 5% of users being on Linux, split into multiple factions that each want us to focus on a different toolkit... low single-digit percentages of our user base. Hate to break it to you, but that just isn't a sane distribution of resources, no matter how loud any particular 1-2% of the user base is.
So, what I see is: if we want to support Qt, then we need someone willing to dedicate themselves to that toolkit and become the official maintainer -- no different than we already have for MacOS (that didn't get off the ground in a serious way until dbsoft stepped in as dedicated maintainer). Every toolkit implementation will have to be maintained by someone really invested in it and daily driving it, who is willing to make this a long term thing. Without that, our options are limited to what we already have in our code base, or some completely agnostic solution like Wine or SDL.

[athenian200]

Without that, our options are limited to what we already have in our code base, or some completely agnostic solution like Wine or SDL.

Well, we do already have preliminary code for an SDL version. And honestly, I do get the appeal of the Wine solution... it lets us focus on Windows and not have to worry about what Linux does.

Now, I'm not saying Linux users will love it if we go that route (they will probably be pissed, and you'll have to anticipate frustration on their part if pragmatism pushes us that way)... but I think an option like that is better than simply saying something like "Pale Moon only runs on Debian and Slackware because everyone else dropped GTK3," you know what I mean? We can support old GTK for a little while longer, probably half a decade if the pattern we've seen so far with GTK2 holds, but at some point it really seems like something is going to have to give, and I don't want that something to be our ability to run on any Linux distro besides the ones with the best legacy support. That's barely better than having to run inside a VM or a Docker container or a Flatpak or something, it's not a Linux strategy.

By the way, I was admittedly curious... what percentage of the userbase is on Linux compared to Mac and Windows, anyway? I had gotten the impression more of our users moved to Linux recently, but maybe it's just those are the more vocal ones frustrated with Windows 11.

EDIT: Did briefly try to run the Windows version of Pale Moon in Wine on Linux just to see how that looks... it seemed to work, videos played and everything, but there were issues with sound, the AppMenu wasn't visible, and showing the menu bar didn't look quite right. But there were no crashes with complex websites and it worked for the most part. I get the feeling that's basically going to be the issue with anything like Winelib or SDL out of the box... visually things may not look quite right compared to normal expectations, but running at all is still better than "hunt down this old toolkit or a special distro," at least IMO.

But really... if the Windows version were to work well enough in Wine... then that would solve several headaches at once without us having to do any additional builds. NPAPI on systems that lack GTK2? "Just use the Windows version in Wine, you'll be okay." GTK3 was dropped? "Use the Windows version in Wine, we tested it and it's fine, that works great on GTK4-only and Wayland-only systems."

And of course, I do think GTK3 will survive longer on BSD and SunOS, solely because I don't think they can go Wayland quite as easily as Linux. So, I'm obviously not eager to drop that code... but I do think if nothing changes, the time may come when almost no Linux distros can use it, but I can still compile my SunOS port. Let's just say there is a reason I ported to Solaris all those years ago... because I knew they were literally in a position where they would have more trouble implementing Wayland than anyone else, even the BSDs, and also are heavily dependent on nVidia's GLX support to function with graphical acceleration. So being tied to GLX/nVidia with no kernel-level support for what Wayland requires to function as a protocol means X11 is probably safer there. It's worth remember Linux is not the only platform using that code... but Linux may become, ironically, a platform we have to port Pale Moon to all over again some day while the other platforms keep using our old Linux code because they're still fundamentally Unix while Linux becomes more of its own thing.

[Moonchild]

By the way, I was admittedly curious... what percentage of the userbase is on Linux compared to Mac and Windows, anyway? I had gotten the impression more of our users moved to Linux recently, but maybe it's just those are the more vocal ones frustrated with Windows 11.

Only 4% as of January this year.
https://forum.palemoon.org/viewtopic.ph ... 62#p269221

[athenian200]

Oh, wow. That's... less than I thought. I was thinking that it was a lot of trouble for something like 10-20% of the userbase... but it was really closer to 5%.

Granted, I do see a certain amount of value in being attractive to Linux users because they are hacker-types and often know their way around a compiler, which means they might be able to contribute code. But this definitely makes the situation seem absurd. 4% of the users require significantly more work on non-web related issues connected to platform code...

If that's the case, our position is significantly stronger on this issue than I thought. If a native Linux application doesn't support the latest toolkit, then they have a problem. But if a cross-platform application with 95% Windows and Mac users doesn't support Linux well, then Linux has a problem. I hate to put it that way, but now I understand why you weren't more worried about this issue...

[mr tribute]

Oh, wow. That's... less than I thought. I was thinking that it was a lot of trouble for something like 10-20% of the userbase... but it was really closer to 5%.

Granted, I do see a certain amount of value in being attractive to Linux users because they are hacker-types and often know their way around a compiler, which means they might be able to contribute code. But this definitely makes the situation seem absurd. 4% of the users require significantly more work on non-web related issues connected to platform code...

If that's the case, our position is significantly stronger on this issue than I thought. If a native Linux application doesn't support the latest toolkit, then they have a problem. But if a cross-platform application with 95% Windows and Mac users doesn't support Linux well, then Linux has a problem. I hate to put it that way, but now I understand why you weren't more worried about this issue...

I don't think anyone is worried about this (non)-issue. The reason I chimed in was because I have time on my hands. I don't watch TV, do social media etc. Linux is my hobby. It's a hobby, not something I rely on for anything. I'm sure this is the case for many Linux users. You can use an iPad for everything these days. So the only real aspect is privacy and for that Linux is pretty good. Pale Moon is also good, but so is LibreWolf.

Just saying that chatting about this was for fun, not expecting anything to come out of it. Linux is always like that. If someone wants something they create it and then they often share it. If people like it then they use it. I would be happy to use Pale Moon with gtk4 and libadwaita just for fun. You can look up teejeetech.com. He ships everything with few dependencies.

There are no problems on Linux (kernel), only possibilities. This is the right mindset. There is also a possibility to not support Linux at all and let the community handle it (if they want to). That is also fine. We all do what we do because we want to, so we should be happy. Linux is about FOSS (privacy) and joy. No one really has to worry about anything because there always pop up solutions sooner or later. I have used Linux for 18 years and anytime there was a problem there was also a solution. With FOSS real problems don't really exist.

People "worry" about Wayland but ultimately it will be a small thing compared to systemd, at least for the foreseeable future.

[andyprough]

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.

I did not realize that @Basilisk-Dev's Qt6 port was so far along. I asked a programmer friend to look at a diff file, and he had a few praising comments -

===============================================================

1. this is a real Qt6 backend, not just a superficial build flag experiment. It adds a new widget/qt platform backend, hooks it into the toolkit selection system as cairo-qt6, creates a QGuiApplication, pumps the Qt event loop, creates native QWindow objects, dispatches mouse/keyboard/focus/wheel events into UXP, adds Qt clipboard support, Qt look-and-feel colors, Qt print settings, Qt screen handling, and a gfxQtPlatform

2. The branch appears to do the hard first step: it creates a selectable Qt toolkit target.
The build system adds:
--enable-default-toolkit=cairo-qt6
and maps that to:
MOZ_WIDGET_TOOLKIT = qt
Then old-configure.in checks for:
Qt6Core Qt6Gui Qt6Widgets Qt6PrintSupport
and assigns those flags to TK_CFLAGS / TK_LIBS.
The new backend includes the expected platform pieces:
widget/qt/nsWindow.cpp
widget/qt/mozqwidget.cpp
widget/qt/nsAppShell.cpp
widget/qt/nsClipboard.cpp
widget/qt/nsLookAndFeel.cpp
widget/qt/nsScreenManagerQt.cpp
widget/qt/nsPrintSettingsQt.cpp
gfx/thebes/gfxQtPlatform.cpp
toolkit/xre/nsQAppInstance.cpp
That is the right architecture, still Goanna/XUL using Qt underneath as the native windowing/event/clipboard/platform layer

3. The Qt path does not appear to require libgtk-3-dev as the toolkit backend. It uses Qt6 packages instead.
However, it still intentionally keeps several Linux desktop stack dependencies:
Pango
Fontconfig/Freetype
GLib/GObject
DBus
X11/GLX
XScreenSaver
That is not a problem, as a Linux browser backend can reasonably depend on those without depending on GTK3 itself.

4. What already seems implemented - The following areas are meaningfully present:
- App startup and event loop
nsQAppInstance creates a QGuiApplication, and nsAppShell integrates with Qt’s event dispatcher. That is a core milestone
- Native windows
nsWindow creates MozQWidget, which is actually a QWindow subclass. It handles top-level windows, dialogs, popups, children, visibility, resizing, moving, focus, fullscreen, title, icons, and cursor shape
- Painting path
There is a Qt graphics platform layer, Qt Cairo surface plumbing, and Xlib-backed drawing for X11. It is enough to plausibly render browser content
- Keyboard and mouse input
Mouse buttons, motion, wheel events, keyboard down/press/up, context menu keys, app-command keys, and basic editor keybindings are mapped
- Clipboard
There is a Qt clipboard implementation for text, HTML, images, arbitrary MIME, and X11 selection clipboard when Qt reports support
- Look and feel
Qt palette colors and Qt default font are mapped into the browser’s look-and-feel system
- Printing, partially
PDF/PS print-to-file plumbing exists, using Qt print settings and UXP print targets

5. Reasonable next priorities:
- Make X11 the explicit first target
Do not pretend it is Wayland-ready. Get Qt6/X11 stable first
- Fix screen/HiDPI basics
Screen coordinate swap, actual per-screen scale, actual window screen detection
- Fix clipboard correctness
Especially generic MIME, image lifetime, primary selection behavior
- Add real IME support
This is essential for non-English users
- Add drag-and-drop
File drops, URL drops, internal tab/bookmark/content drag operations
- Clarify printing scope
Either support only print-to-PDF cleanly, or implement real Qt print dialog/native printing [why not just use the Linux native cups printer dialogue here? -- Andy]
- Decide whether NPAPI/plugin support matters
If it matters, the missing plugin port/XEmbed story is a major item

==================================================

Maybe this work on Basilisk-Qt6 could be the test vehicle for transitioning to a longer-term solution, while leaving Pale Moon alone for the moment since gtk3 is not going anywhere soon?

[andyprough]

I'd like to build Basilisk-Qt6 in a Debian VM and take it for a spin. But first I'd like @Drugwash's errors below to be addressed, and to find out if we have a .mozconfig we can use:

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

[jarsealer]

I also might build and test the Basilisk Qt6 port in a Fedora KDE VM (once it can compile without errors), I hope 8 GiB of ram are enough however, since I've never compiled Qt stuff.

[Basilisk-Dev]

I'd like to build Basilisk-Qt6 in a Debian VM and take it for a spin. But first I'd like @Drugwash's errors below to be addressed, and to find out if we have a .mozconfig we can use:

This is the mozconfig I was using during testing. I use Clang for development and release builds, so you'll need to remove the clang stuff if you want to use GCC and make adjustments if you'd like to try Pale Moon or Epyrus with QT6 instead. I have a separate mozconfig I was using for debugging, basically just set optimizations to -O1 and set --enable-debug and --enable-debug-symbols and --disable-strip. Tried to comment it for you the best I can.

Code: Select all

# objdir
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-qt6
# Set Basilisk version to date timestamp
export BASILISK_VERSION=1

# Use clang/llvm toolchain
export CC="clang"
export CXX="clang++"
export AR="llvm-ar"
export NM="llvm-nm"
export RANLIB="llvm-ranlib"
export LD=ld.lld

# Force LLVM for HOST tools as well
export HOST_CC=clang
export HOST_CXX=clang++
export HOST_AR=llvm-ar
export HOST_RANLIB=llvm-ranlib
export HOST_NM=llvm-nm
export HOST_LD=ld.lld

# Ensure static archives always get a symbol table (__.SYMDEF).
# UXP build logic assumes ar creates this implicitly,
# but with ThinLTO + LLVM bitcode that is no longer guaranteed.
# Without the 's' flag, ld/lld will fail with:
#   "archive has no index; run ranlib to add one"
# This is especially critical for HOST tools (mbsdiff, mar, etc.).
export ARFLAGS=crs
export HOST_ARFLAGS=crs
export ARFLAGS=crs
export HOST_ARFLAGS=crs

# ThinLTO with Clang/LLVM. -Wl,--undefined-version is needed due to differences between GNU ld and lld
export LDFLAGS="-flto=thin -fuse-ld=lld -Wl,--undefined-version"

#No ThinLTO
#export LDFLAGS="-fuse-ld=lld -Wl,--undefined-version"

# O3 is stable and produces faster binaries than O2, -w to suppress all warnings, -flto=thin for ThinLTO
ac_add_options --enable-optimize="-O3 -w -flto=thin"

#No ThinLTO
#ac_add_options --enable-optimize="-O3 -w"

# Standard build options for Basilisk
ac_add_options --enable-application=basilisk
ac_add_options --enable-default-toolkit=cairo-qt6
ac_add_options --enable-jemalloc
ac_add_options --enable-strip
ac_add_options --enable-devtools
ac_add_options --enable-av1
ac_add_options --enable-webrtc
ac_add_options --enable-gamepad
ac_add_options --enable-pie
ac_add_options --enable-update-channel=release
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-necko-wifi
ac_add_options --enable-updater
ac_add_options --with-pthreads
ac_add_options --enable-official-branding

export MOZILLA_OFFICIAL=1

ac_add_options --x-libraries=/usr/lib64

export MOZ_PKG_SPECIAL=qt6

I haven't worked on it in a few days, still has a lot of bugs to fix. I'd be using this version daily if we got it merged in and would be willing to maintain upgrading to future QT versions as they come out since upgrading QT releases is substantially easier than upgrading GTK releases.

Or, if all we're doing anyway is trying to provide an integration layer, then why not run on Wine (since win32 isn't going away in the foreseeable future) and do away with native Linux builds? All things that roll around in my head reading this discussion.

This would break support for everyone not using x86. I know nobody else is using LoongArch like I am, but I know for sure some people use aarch64 Linux builds on hardware like Raspberry Pi.

[ownedbywuigi]

Or, if all we're doing anyway is trying to provide an integration layer, then why not run on Wine (since win32 isn't going away in the foreseeable future) and do away with native Linux builds? All things that roll around in my head reading this discussion.

Spoiler alert: Browsers on Wine are slow. UXP has a reputation for being slow in the general browser community. Put two and two together and you literally have IE speeds of slow on Linux

PLUS you’d piss off a LOOOOT of people if you got away with Linux builds all together.

[Moonchild]

Don't misunderstand me here: just things rolling around in my brain playing "what if" scenarios for "what if Linux goes mad and pushes for GTK4+Wayland only" hypotheticals Not having any plans or anything. Just to be 100% unambiguously clear.
I'd sooner just toss it all to the Linux community to maintain (and not having Linux builds) than forcing angry neckbeards to use Wine when they don't want to touch Microsoft even by proxy I know better.

[ownedbywuigi]

Don't misunderstand me here: just things rolling around in my brain playing "what if" scenarios for "what if Linux goes mad and pushes for GTK4+Wayland only" hypotheticals Not having any plans or anything. Just to be 100% unambiguously clear.
I'd sooner just toss it all to the Linux community to maintain (and not having Linux builds) than forcing angry neckbeards to use Wine when they don't want to touch Microsoft even by proxy I know better.

It's a GNOME developer's wet dream for GTK4+Wayland to only exist, literally any other DE would either ride out GTK2/3 or just use Qt..

[athenian200]

Don't misunderstand me here: just things rolling around in my brain playing "what if" scenarios for "what if Linux goes mad and pushes for GTK4+Wayland only" hypotheticals Not having any plans or anything. Just to be 100% unambiguously clear.
I'd sooner just toss it all to the Linux community to maintain (and not having Linux builds) than forcing angry neckbeards to use Wine when they don't want to touch Microsoft even by proxy I know better.

Yeah, this is where we are with this right now.

My personal prediction is that XWayland is here to stay and we can safely target that for the foreseeable future. But we have to consider the worst-case scenario of GTK3 being dropped, and Linux going native Wayland only and killing XWayland to "make a statement," because Linux can be weirdly political and idealistic rather than pragmatic at times, and has shot itself in the foot with that mentality before.

Like, to ground this more in reality... the Red Hat/Freedesktop.org people, the very people pushing Wayland, play a big role in maintaining XWayland for their enterprise customers because they know 40 years of Unix software were built on X11. Right now, the adults are still in the room, and they know they need that compatibility layer, and that a lot of past software that's already written isn't going to be rewritten for Wayland. IBM does not have a history of killing backwards compatibility, I think they still ship systems that run COBOL code for some enterprises. GNOME, the people we all love to hate... has tried offering things like GNOME Flashback and GNOME Classic desktop options that make their modern offering look more like GNOME 2.

What all this adds up to, is that they are aware that they need a compatibility layer, that some people will be compiling and running old code, and that some people are not happy with the modern GNOME UI. They are hoping XWayland and stuff like GNOME Classic sessions that make a half-way attempt to look more like GNOME 2 will be enough of a peace offering to keep older people who have investments in X11 code and don't like modern GNOME in their orbit even as they move forward with their modern stack. So far, what they're signaling is more that they want new applications written in Wayland, and are trying to discourage the use of X11 and GTK2, but not outright forbid it or force people to hand-compile the packages like we had to do with Python 2. They appear to be slow-walking this one, to the point that I would be surprised if they drop the XWayland compatibility layer before 2040 (and maybe not even then). XWayland isn't seen as the enemy of Wayland adoption, it's seen as the price of getting people to use Wayland for everything that supports it already and not just get mad and run a full X11 desktop session the moment they hit something that wasn't designed for Wayland like they were doing before. They did not want to build that layer, they only built it in 2021 because they knew people would never accept Wayland without it. That tells us a lot, really.

The scenario we're preparing for is that as time passes and management turns over, the younger Wayland/GNOME idealists somehow get into the control room at IBM and start nuking everything, killing XWayland, ripping all GTK versions older than 4 out of EPEL, and downstream distros who can't maintain security patches themselves just drop older GTK and apologize that everything is breaking because they don't have the manpower to do what Red Hat won't do anymore.

Why do I think they won't do it? Because Wayland advocates saw what happened when they tried to push Wayland with no X11 fallback already... they saw that people rejected it. Also, at some point it may be seen as more like the Unix equivalent of Wine or DOSBox. A compatibility layer for older software. If you want modern features, you use Wayland... if you want to run old software, XWayland is there to catch you. That's not incompatible with the worldview of more sane pro-Wayland people, there are probably people in that camp who want X11 to be the old thing that needs a compatibility layer, and Wayland to be the thing modern applications are written in. Only the truly radical ones want to make sure no one ever runs an old Unix application that hasn't been reworked runs on top of Wayland ever again, or feel offended by the use of it. And then... if you think about what it would be replaced with, it's even sillier. Get rid of XWayland, those people will run the Windows version in Wine, or the X11 version in a VM running an old version of Linux, which probably isn't the direction they want unless they're radical and have no common sense.

Really, I think we don't need to worry about Wayland as much as we need to worry about older GTK being removed, because it's a complex toolkit tied into too many GNOME packages associated with older GNOME desktops, and not a simple toolkit like Motif or Qt or most other toolkits you can think of. This isn't paranoia because we know Linux distros will do things like that. That's what I actually think, but the Wayland angle complicates things and naturally makes people wonder if it's even worth moving to a newer toolkit version but sticking with X11, which is a lot more doable than going native Wayland.

[andyprough]

OK, I was able to build Basilisk-Qt6, and I'm using it right now in MX Linux 25 KDE version, in an X11 session.

I can't type into the browser, but I can copy and use the mouse to paste into it. I'm sending this message from within it. I'll try to add a screenshot.

Error console is not working.

Nope, doesn't look like I can add a screenshot, not from within it. I'll post a screenshot from regular Pale Moon soon, along with my build steps.

Watching a youtube video. Sound is working. Video and sound are very clear. Doesn't seem to be taxing the CPU at all.

[athenian200]

OK, I was able to build Basilisk-Qt6, and I'm using it right now in MX Linux 25 KDE version, in an X11 session.

Watching a youtube video. Sound is working. Video and sound are very clear. Doesn't seem to be taxing the CPU at all.

Good to know, it sounds like that Qt port is further along than I thought...

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's just worth noting that it would be a big shift, since Firefox and Pale Moon have pretty much always been GNOME-first and essentially treated GTK and various GNOME assumptions as "the system toolkit" for Linux historically in so many ways, just like Win32 on Windows or Cocoa on Mac.

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

[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..?

[andyprough]

Here's my steps for building Basilisk-Qt6. I used GCC just because I'm unfamiliar with Clang:

0. Confirm you are in an X11 session if you build it on KDE like I did -

Code: Select all

echo "$XDG_SESSION_TYPE"

1. Update, and Install build dependencies. Note - I had to download and 'sudo apt install' the deb package for autoconf2.13 from Debian Bookworm at packages.debian.org, which installed fine, but it's not available on Debian 13:

Code: Select all

sudo apt update
sudo apt install git ca-certificates curl wget build-essential pkgconf autoconf2.13 m4 perl patch python3 python-is-python3 python3-dev python3-dbus yasm zip unzip xz-utils tar bzip2 ccache   libasound2-dev libpulse-dev libxt-dev libx11-dev libx11-xcb-dev libxext-dev libxrender-dev libxfixes-dev libxss-dev libxi-dev libxcomposite-dev libxdamage-dev libxrandr-dev libxcb1-dev libxcb-shm0-dev libxcb-render0-dev libxcb-render-util0-dev libxcb-xfixes0-dev libxcb-glx0-dev libxcb-randr0-dev libxcb-keysyms1-dev libxcb-cursor0 libxcb-cursor-dev libegl-dev libgl-dev libglu1-mesa-dev mesa-common-dev zlib1g-dev libssl-dev libsqlite3-dev libbz2-dev libffi-dev libdbus-1-dev libdbus-glib-1-dev libglib2.0-dev libpango1.0-dev libfontconfig-dev libfreetype-dev libharfbuzz-dev   qt6-base-dev qt6-base-dev-tools qt6-base-private-dev qt6-qpa-plugins gdb strace

2. Create a source directory

Code: Select all

mkdir -p ~/src
cd ~/src

3. Clone Basilisk-Qt6

Code: Select all

git clone https://repo.palemoon.org/Basilisk-Dev/Basilisk.git basilisk-qt6
cd basilisk-qt6

4. Initialize the UXP platform submodule

Code: Select all

git submodule init
git submodule update --init platform

5. Point `platform/` at the Qt6 UXP-contrib repo and branch

Code: Select all

git submodule set-url platform https://repo.palemoon.org/Basilisk-Dev/UXP-contrib.git
cd platform
git fetch origin qt6
git checkout -B qt6 origin/qt6
cd ..

5.1. Verify:

Code: Select all

git -C platform branch --show-current
git -C platform log --oneline -5

The branch should show: qt6

6. Create .mozconfig. Run this from the top-level `basilisk-qt6` directory. This is my GCC version, not @Basilisk-Dev's Clang version, so there's some small differences:

Code: Select all

cat > .mozconfig <<'EOF'
# Build output directory
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-qt6

# Adjust this for your VM.
# -j4 is a safe starting point for many VMs.
mk_add_options MOZ_MAKE_FLAGS="-j4"

# Set Basilisk version to date timestamp
export BASILISK_VERSION=1

# Basilisk application
ac_add_options --enable-application=basilisk

# Experimental Qt6 backend
ac_add_options --enable-default-toolkit=cairo-qt6

# Conservative first build: GCC, no LTO, no Clang, no ThinLTO
ac_add_options --enable-optimize="-O2 -w"

# Standard-ish Basilisk options
ac_add_options --enable-jemalloc
ac_add_options --enable-strip
ac_add_options --enable-devtools
ac_add_options --enable-av1
ac_add_options --enable-webrtc
ac_add_options --enable-gamepad
ac_add_options --enable-pie
ac_add_options --enable-update-channel=release
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-necko-wifi
ac_add_options --enable-updater
ac_add_options --with-pthreads

# Branding / official flag.
# Fine for private testing. Be careful about redistribution rules.
ac_add_options --enable-official-branding
export MOZILLA_OFFICIAL=1

# Debian/MX amd64 library path.
# Do not use /usr/lib64 on Debian/MX.
ac_add_options --x-libraries=/usr/lib/x86_64-linux-gnu

# Mark package flavor
export MOZ_PKG_SPECIAL=qt6
EOF

7. Configure
Explicitly tell Qt to build for X11:

Code: Select all

export QT_QPA_PLATFORM=xcb

Then:

Code: Select all

./mach configure

8. Build

Code: Select all

./mach build

This may take awhile. If your VM has low RAM, reduce jobs in `.mozconfig`:

Code: Select all

mk_add_options MOZ_MAKE_FLAGS="-j2"

Then rerun:

Code: Select all

./mach build

9. Package [this failed for me]:

Code: Select all

./mach package

Find the output:

Code: Select all

find obj-qt6/dist -maxdepth 3 -type f \( -name "*.tar.*" -o -name "*.zip" \) -print

Since packaging failed, I ran Basilisk-Qt6 directly via mach run:

Code: Select all

QT_QPA_PLATFORM=xcb ./mach run

10. Clean rebuild command, if needed, if configure/build state gets messy:

Code: Select all

./mach clobber
rm -rf obj-qt6
./mach configure
./mach build

Here it is. Visually it seems the same as regular Basilisk to me, except that the menus aren't as polished:

Screenshot_20260507_154338.jpg

[athenian200]

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..?

Yeah, a lot of toolkits have embedded Qt or WebKit of some variety, but I don't think that has anything to do with whether they work for other applications. The only thing QtWebEngine affects, if anyone wants to take advantage of it, is a really easy way to implement the equivalent of SubWebview on Linux without shipping a whole copy of Chromium Embedded Framework. Otherwise, it's kind of talking about apples and oranges... 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.