Linux Pale Moon with Qt toolkit

[athenian200]

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.

Yep, that's pretty much the only reason Qt6 is on the table... it's seen as an easier transition than GTK4 would be. I did some research, and the problem is basically this... mapping a toolkit-neutral thing that relies on other libraries for desktop integration, onto another toolkit-neutral thing that relies on other libraries for desktop integration, just doesn't make any sense.

https://tesk.page/2024/06/03/libadwaita ... tk-4-today

These pictures will explain exactly what GTK4 is, and why it actually isn't that useful for desktop integration. GTK4 basically went from being what we'd recognize as a native widget toolkit useful for platform integration... to something more like a cross-platform GUI toolkit that provides abstract widget primitives, which can be made to look native on anything if you use the right "glue layer." Instead of providing widgets itself, it presents neutral widget primitives and uses things like libgranite and libadwaita to map onto the real native widget toolkits. It would even let us draw our own widgets. Presumably MATE or Cinnamon could use a libclassic to make GTK4 usable for themselves, but that means apps targeting them won't look native on GNOME and vice-versa.

But yeah... it seems like this may not be that pressing an issue simply because, in a pinch, we don't "need" a widget toolkit to run on Linux at all, it's just that having one (rather than doing SDL, XLib, etc) really helps with desktop integration and everything feeling native, which Linux users really appreciate.

[Drugwash]

it’s important to realize that GTK is meant to be built with a complementary platform library that extends its functionality when targeting a specific platform.

Somebody please help me understand this correctly: one can either build with plain GTK4 in order for their app to integrate into any and all platforms, or build with GTK4 + a specific platform library in order to target only that specific platform? Did I get this right?

Because after reading all that (and seeing those horribly ugly UI screenshots) I'm more confused than before. However it all seems to me that they indend to take over the very base of UI building for any and all Linux, and leave it to individual distros to provide only the narrow niche of widget tweaking. Kinda how google took over the web standards, or cloudflare for gatekeeping, and I'm sure there would be other examples of forced centralisation.

Am I hallucinating?! Do we live on Planet Highlander where there can be only one - of anything...?!?

[athenian200]

Somebody please help me understand this correctly: one can either build with plain GTK4 in order for their app to integrate into any and all platforms, or build with GTK4 + a specific platform library in order to target only that specific platform? Did I get this right?

Because after reading all that (and seeing those horribly ugly UI screenshots) I'm more confused than before. However it all seems to me that they indend to take over the very base of UI building for any and all Linux, and leave it to individual distros to provide only the narrow niche of widget tweaking. Kinda how google took over the web standards, or cloudflare for gatekeeping, and I'm sure there would be other examples of forced centralisation.

More than likely they were addressing criticisms that GTK3 was "only suitable for GNOME's needs" made by MATE and Cinnamon, by giving them something more abstract they could build their own stuff on when the time comes for them to rebase what they've built on newer GTK (which they always do when the current version is retired).

Well, really it's not a new idea. Note that we use Win32 on Windows, Cocoa on Mac, and GTK on Linux... but use our own abstract widgets internally that the others are mapped onto, so that we (and XUL extensions) can look native on any platform without changing how our underlying code deals with things in a more abstract sense. GTK4 is basically GNOME's attempt at a similar idea (different architecture, but similar idea) to allow all the forks of GNOME to continue using the underlying GTK toolkit with the "under-the-hood" improvements still being made, but without too much GNOME-specific stuff layered on top that wouldn't work in classic-style environments. I did double-check, and can confirm "raw" GTK4 applications do not look native on GNOME or anything else, they look neutral and unstyled like a blank canvas, just like in those screenshots.

The biggest downside is it means anyone targeting GTK4 would likely have to target a specific desktop that uses it, since they'll likely be using libadwaita (GNOME), libgranite (ElementaryOS), libclassic (probably future MATE/Cinnamon), and whichever one you compile against... that's what your application looks like. If I'm understanding correctly? Of course, this is existing alongside Qt and all the other stuff. If anything, this actually seems like they were afraid of those desktops forking GTK3 if they made GTK4 too GNOME-centric, and were hoping to offer them something that will keep them in the loop while continuing to go their own way design-wise, though it remains to be seen if this strategy will work.

[Drugwash]

The biggest downside is it means anyone targeting GTK4 would likely have to target a specific desktop that uses it, since they'll likely be using libadwaita (GNOME), libgranite (ElementaryOS), libclassic (probably future MATE/Cinnamon), and whichever one you compile against... that's what your application looks like.

Well I'm still unclear on this one but if it's as you say then it would definitely lead to a huge fragmentation of the Linux community, and certain developers might simply give up rather than build X flavors of their app - one for each possible desktop.

In my mind I still hope that we just slightly misunderstand the concept, and that it's possible for an application built against a raw GTK4 - as you say - to simply "connect" to the GTK4 version on the target machine, embracing the style used to build that particular copy of the GTK4 toolkit for the respective desktop. That would definitely make sense for a smart design. But maybe I'm giving them GTK team too much credit...

I'm of half mind to try installing GTK4 here from Rob's backports and perform some test with the available apps. But I'm a little afraid not to bork this system now when it's so close to [my view of] perfection. Qt6 was already a gamble, and I passed - for now - on upgrading Qt5 from 5.9 to 5.15 which is also available from Rob's backports. I'll think about it.

[Moonchild]

In my mind I still hope that we just slightly misunderstand the concept, and that it's possible for an application built against a raw GTK4 - as you say - to simply "connect" to the GTK4 version on the target machine, embracing the style used to build that particular copy of the GTK4 toolkit for the respective desktop. That would definitely make sense for a smart design.

In practice I don't think this can work, unless your application literally leaves every part of the GUI up to whatever an underlying lib determines the display should be, by only targeting the most abstract of UI definitions. That doesn't work very well for the vast majority of applications. Basically only those designed for and built from the ground up for GTK4 would actually be able to do this, and you'd have to severely limit yourself into what you're going to do in the UI -- think the drab look of UWP "apps" on the desktop with several paradigms enforced by the overly generic design choices that must be made to cater to very high levels of abstraction, including control metrics. The result will almost inevitably be a layout with lots of whitespace "just in case metrics are small on such and such display system", with minimal decorations, and monochrome/vector graphic elements. To drag back up the analogy from the other topic I just posted in: it's Bauhaus all over again.

[Drugwash]

unless your application literally leaves every part of the GUI up to whatever an underlying lib determines the display should be, by only targeting the most abstract of UI definitions.

Maybe that's the whole idea of the concept. Otherwise it just wouldn't make sense in my opinion. Let's not forget that GTK(3) is quite adaptive, it usualy takes into account very well the settings in the CSS as well as any changes that appear at runtime, and styles the widgets accordingly. If GTK4 improves on that and knows how to steer the styling library - be it libadwaita or whatever other compatible - so that it wouldn't mess the widgets' layout then it may just be feasible.
Darn, can't believe I got to make the apology of GTK4 after all I've read around about it. I mean... there should be some way to just find out whether we're just dreaming big or it's actually working? If only I had another spare drive for a system clone, I'd try installing GTK4 and some styling library, if possible. It got me intrigued.

[Daemonratte]

For anyone interested with a (hopefully) more lightweight browser, I do plan on reviving Galeon with my new gtk2 fork. I hope that I can get most Pale Moon extensions to work properly.
I hope I can also improve performance on gtk2 build of Pale Moon.
Speaking of:
Is there anything I can improve in gtk2 that would benefit you guys?

[solitude]

For anyone interested with a (hopefully) more lightweight browser, I do plan on reviving Galeon with my new gtk2 fork. I hope that I can get most Pale Moon extensions to work properly.
I hope I can also improve performance on gtk2 build of Pale Moon.
Speaking of:
Is there anything I can improve in gtk2 that would benefit you guys?

The disagreement over the future of Galeon split the development team in 2002 ...This event marked the beginning of the browser's popularity decline, which led to its discontinuation in September 2008

Pretty old fork.. by reviving do you mean just porting it to GTK2 as it is, or maintaining and developing it?

[Daemonratte]

Pretty old fork.. by reviving do you mean just porting it to GTK2 as it is, or maintaining and developing it?

Oh, it already uses GTK2
I want to port it to use the Goanna engine and revive GtkMozEmbed (so you can embed the engine in gtk2 applications).
The original Galeon browser didn't support extensions though and I want to change that.

[dinosaur]

I'd gladly use it on a daily basis instead of the Gtk3 version I'm using now.

Well, you thankfully still can compile PM against GTK2, the only problem with the latter being with distros that stop providing packages for it...

Thus why a Qt port feels more than desirable to me: it avoids the GTK 3/4 plague, and still allows to use GTK2 themes (i.e. no difference in "look and feel" with today's GTK2 PM builds)...

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, .../...

Yes, Qt5 is mature and stable, whereas Qt6 is still a moving target, with serious issues and incompatibilities between minor releases (e.g. 6.2 vs 6.3), that IMHO makes it "too young" and not widely adopted enough (not all distros got Qt6 and not all of them got the same Qt6 minor version), at least for now.

[Daemonratte]

Well, you thankfully still can compile PM against GTK2, the only problem with the latter being with distros that stop providing packages for it...

Thus why a Qt port feels more than desirable to me: it avoids the GTK 3/4 plague, and still allows to use GTK2 themes (i.e. no difference in "look and feel" with today's GTK2 PM builds)...

That's why we forked gtk2 and soon lots of gtk2 software and DEs. We want to prevent the deprecation of gtk2 and there's a good chance we can stop it, because major software still uses it in one way or another. For example Ardour or the Debian graphical installer.

[Drugwash]

Well, you thankfully still can compile PM against GTK2 [...]

I know, it's just a matter of switching 3 for 2 in .mozconfig. I chose Gtk3 though because it's the native toolkit for the Cinnamon DE I use, and themes for Gtk3 are using a somewhat "classic" version of CSS compared to the "weird" .rc configuration in Gtk2 themes. I could never get that one right, and as a result the scrollbars in all Gtk2 apps and Qt apps that follow the Gtk2 theme, all exhibit an annoying bug. Guess I'll have to fix it at some point, at least for the benefit of Qt apps.

Yes, Qt5 is mature and stable, whereas Qt6 is still a moving target, with serious issues and incompatibilities between minor releases (e.g. 6.2 vs 6.3) [...]

That's precisely what I was thinking of. Qt5 is a sure bet, and I believe/hope it will still be for a while. Qt6 is something to look forward to but not bet on, just yet - it might be just too early. Well, just an honest opinion is all. Problem is, for us users of old systems that barely get an early version as backport (Qt 6.2.x), these inconsistencies/incompatibilities between minor versions might be a real show stopper, if developers decide to use incompatible Qt API.

Off-topic:

For example Ardour [...]

Kept seeing people mentioning Ardour on Devuan forums, so I decided to find out what it was. That's exactly how I asked in the search engine: what is Ardour? What do you think the stupid duck answered? A truckload of dictionary definitions explaining what 'ardour' meant in English. But I asked what it was, not what it meant! Guess it's too subtle of a semantics difference for an "intelligent" engine to pick up.

Anyway, I finally found out, went to their git, cloned the repo and then... realized I already had a truckload of dependency packages in some folder, specifically for Ardour, meaning at some point in the past I actually knew about it and wanted to install/test it, or something. Damn short memory of mine!

In the end I managed to build it succesfully, not before getting awfully mad at the stupid waf building system that makes it so damn difficult to provide a simple flag that for some reason was left out of the damn long and convoluted configuration file. It simply needed -std=cxx17 for CXX_FLAGS otherwise it would bail out at about 4-5% in. But before that I got awfully mad at it for the first time when it kept showing missing dependencies one by one instead of all at once, so everytime I installed a missing dependecy and reran the config it was spitting out another missing dependency, and so on and so forth until it drove me close to throwing this notebook out the window. Only close to, thankfully.

But... what the heck am I going to do with it?! I have no idea whatsoever!

[Daemonratte]

I know, it's just a matter of switching 3 for 2 in .mozconfig. I chose Gtk3 though because it's the native toolkit for the Cinnamon DE I use, and themes for Gtk3 are using a somewhat "classic" version of CSS compared to the "weird" .rc configuration in Gtk2 themes. I could never get that one right, and as a result the scrollbars in all Gtk2 apps and Qt apps that follow the Gtk2 theme, all exhibit an annoying bug. Guess I'll have to fix it at some point, at least for the benefit of Qt apps.

No worries. There'll be a tool to create themes easily without any prior knowledge for many gtk2 engines and we'll also add a theming engine for gtk2 that gives you the option to theme it with CSS

[Drugwash]

No worries. There'll be a tool to create themes easily without any prior knowledge for many gtk2 engines and we'll also add a theming engine for gtk2 that gives you the option to theme it with CSS

Yep, I know, have read your replies around here. Still I'd like to understand the idea, the concept that those rc files are following.
As for CSS themes there's Themix/Oomox but it's limited to colors only, whereas sane old-school themes do use images for certain widgets. I've seen that old toy too which only sets a couple colors to Gtk2 themes. Lame!

Off-topic:
BTW, I tried to resume reading your thread at the Devuan forums and recently it became unreachable for unregistered users, and when I tried to register I was met with sheer idiocy: forced convoluted password, insane math calculations for a so-called captcha (which duck.ai solved in a blink of an eye for me so what gives!?). So I said «fuck it» and gave up, won't go there again, ever. You may wanna relay that to your forum admins.

[Basilisk-Dev]

If people are still interested in a QT fork I might pivot back to experimenting with this. Please let me know if that is still something people want.

[Drugwash]

I'm definitely not one of the people who would matter in this decision of yours but for what it's worth I would very much like to see this go forward to a daily usable state. Just, if possible, please make it compatible with Qt 6.2 since there's no higher version backport for older systems (Ubuntu 18.04 and derivatives).
Alternatively, you may switch to Qt5 - again, not higher than 5.9 - if that would prove easier to implement, then gradually add Qt6 to be future-safe. Your choice.

[andyprough]

If people are still interested in a QT fork I might pivot back to experimenting with this. Please let me know if that is still something people want.

For sure! That's pretty awesome what you were able to do already, it would be kind of tragic to let it die by the wayside.

[athenian200]

If you can get the Qt port stable and usable, I'd be open to offering a Qt version of Epyrus. I always said no to GTK2 because it was a dead end... but it seems to me like there is a certain logic to offering GTK3 and Qt versions of Epyrus.

I'm tempted partly because this would be a more modern port, and partly because I remember what it was like being a KDE user 20 years ago and being annoyed at how Firefox only supported GTK, which I thought of as GNOME's toolkit. Especially during that weird gap where Konqueror wasn't kept up-to-date and wasn't available out of the box anymore for whatever reason. So if I get the chance today to not continue in that tradition, well... yeah, I'd be offering what I would have always wanted back when I was a Linux user.

I admit, I have no idea if this would actually solve the problem of toolkit churn, if a Qt port would be easier to keep up-to-date enough to run on modern distros, but I still find the idea interesting if only because it makes more intuitive sense than offering old GTK or slightly newer GTK in my mind. Plus, a lot of the work has been done... I wasn't really sold on putting in the work if I wasn't sure it was viable or sustainable, but just the fact that it's actually on the table now makes it way more appealing than it was as a theory or an idea.

Plus, this is a way to get an alternative that's maintained by someone who actually uses Linux as a daily driver. I have been experimenting with stuff on Linux in a VM, but it's been suggested that it should be maintained by someone who would use it all the time... and the fact is, I don't use Linux all the time. I'm usually either on Windows or OpenIndiana, and have basically zero interest in daily-driving Linux outside of VMs and debugging things for people who do use it.

[solitude]

If people are still interested in a QT fork I might pivot back to experimenting with this. Please let me know if that is still something people want.

Pale Moon Qt version would be pretty cool, I'd use it.

[ownedbywuigi]

Off-topic:

If people are still interested in a QT fork I might pivot back to experimenting with this. Please let me know if that is still something people want.

Can you port your changes to eUXP in a separate branch? I wanna experiment with it, and potentially fix any issues