Linux Pale Moon with Qt toolkit

[Attronarch]

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.

DItto. Same for Epyrus Qt.

[geraldh]

I'd also be interested in Palemoon and Epyrus QT versions, especially if the GTK2 versions are going to disappear..

[athenian200]

I'd also be interested in Palemoon and Epyrus QT versions, especially if the GTK2 versions are going to disappear..

Off-topic:
The Pale Moon GTK2 version won't be disappearing any time soon. And even if it got into a bad enough state on modern distros that we didn't feel right offering it up for download anymore (it's getting there on Arch), we would be unlikely to remove the code for people that want to build themselves.

Also, Epyrus never had a GTK2 version. So if you've used Epyrus, you have pretty much used the GTK3 version.

But yeah, I'm genuinely curious at this point if people would prefer a Qt version over GTK3... if it would be something more people would use.

[meatloaf]

I would much prefer to see Qt as the new 'toolkit of choice' on Linux compared to anything gtk. I still build a gtk2 version of Pale Moon, though, and probably will until it stops working (or until I can stop patching it easily) unless a Qt version comes along. I'm very in the 'eyeing BSD with interest' camp these days, though. Using Firefox with gtk3 is horrible if I ever have to save a file: the filepicker is so unbelievably worse in gtk3 compared to gtk2 it's not even funny.

[Basilisk-Dev]

Using Firefox with gtk3 is horrible if I ever have to save a file: the filepicker is so unbelievably worse in gtk3 compared to gtk2 it's not even funny.

Off-topic:
Semi-related, but I'm planning on implementing XDG desktop portals support as part of my goal of modernizing our Linux code. This allows, for example, a GTK3 program to use the same filepacker as KDE/QT programs when running under KDE, or vice versa. A KDE/QT program can use the GNOME File picker when running under GNOME.

[Drugwash]

Off-topic:

A KDE/QT program can use the GNOME File picker when running under GNOME.

[deleted by moderator] just make sure the listView headers don't overwrite from one Qt version to another (in ~/QtProject.conf). Qt 6.2 still isn't fixed in that regard, had to jump through hoops to separate Qt5 settings from Qt6's.
Well, the other way around may not be such a bad idea, the Gtk3 version might get redeemed a bit under KDE.

[Basilisk-Dev]

Off-topic:

[deleted by moderator] just make sure the listView headers don't overwrite from one Qt version to another (in ~/QtProject.conf). Qt 6.2 still isn't fixed in that regard, had to jump through hoops to separate Qt5 settings from Qt6's.

Fuck yes. Most modern desktop environments allow this. Firefox can use this functionality for example. XDG portals are readily available on most modern desktops including GNOME, KDE, and (I think but I'm not 100% sure) XFCE. I plan to implement this just like in Firefox, where it can be disabled both via overriding env vars or via an about:config option. Use your brain, you seem to be a smart man. If you don't like the feature disable it.

Nobody is "destroying QT's chance of saving the day". Please do more research before making comments like that. Forgive me for trying to modernize something. I think I'm going to just stop working on improving our Linux support. Nobody else seems to actually be interested enough in doing it to actually write the code to do it, even though plenty of people are more than happy to complain about our Linux support being dated. It's obvious nobody else cares enough to put in work to improve it so I shouldn't waste my time either.

Additionally, every time I try to provide suggestions or add new features, even when optional, people complain or have different opinions and I'm tired of wasting my time on posts like this when I could actually be writing code to improve things for every Pale Moon, Basilisk, and Epyrus user. The QT frontend is off. I'm only doing web compat and bug fixes going forward. If someone else is interested in the QT frontend feel free to PM me and I can help you understand what was implemented and how to move forward from here.

Thank you for helping me understand why Moonchild's signature says Linux makes everything difficult.

[Drugwash]

Off-topic:
Apologies for my reacting so abrupt but you didn't mention it was going to be optional. Even so, an obscure about:config key may be difficult to discover by the average user. If it were in Preferences then it would be alright I guess. Gtk3's dialog is bad, I'm not the only one to say it, so the chance to use the original one would be preferable once the user has specifically chosen the Qt build.
I know there are people that want full integration by all possible means but that shouldn't come detrimental to usability, IMHO. So yeah, choice would be preferrable.

There are others who can't wait for a Qt build, and I can only suspect we are mere users not developers, so the most we could help with are ideas and testing. Maybe you noticed I tried hard to build it as it was, and failed too many times. It takes two and a half hours to build - if everything goes as planned, but I've had it bail out at the last moment. Still, I'm willing to test and report issues or ideas. Yeah, it's difficult but sometimes people just don't have a decent choice.

So please don't take it so hard. It would be a waste of your effort, and we would all lose in the long run.

[Basilisk-Dev]

Off-topic:
You’re fine

[Drugwash]

Off-topic:
Thank you. And again, my apologies.

[athenian200]

Off-topic:
Nobody is "destroying QT's chance of saving the day". Please do more research before making comments like that. Forgive me for trying to fucking modernize something. I'm tempted to just stop working on improving our Linux support because every time I try to people complain or have different opinions and I'm tired of wasting my time on posts like this when I could actually be writing fucking code.

Yeah, that is how people make me feel around here sometimes... which is why it took me so long to even advocate for modernizing the Linux code in the first place. It was so much easier to modernize the Windows code and figure out the line as to what it made sense to keep or discard as time went on by comparison (though granted that was likely because we already told the "XP forever" users to go pound sand more or less). I hope you don't give up because of him not understanding how XDG portals work or not realizing that this kind of thing can be controlled by a pref.

And honestly, I did work on the Python 3 support mostly because of Linux users complaining about Python 2 being too hard to use/find.

EDIT: Goddamn it. Apparently he's done. I hate this community so much. Maybe we should just drop Linux support entirely at this point, and let some half-baked fork worry about it. LOL. Not serious, but in that mood.

[Basilisk-Dev]

Off-topic:

EDIT: … Apparently he's done.

I’m going to keep working on it slowly, but Linux/*nix improvements are going to be bumped much lower in my priority list going forward if people are going to constantly complain along the way.

One thing I’ve come to appreciate after switching to MacOS on my laptop is that you only have one target. One toolkit. One OS configuration. Same with Windows. On Linux/BSD/etc you have a ton of toolkits, daemons, system libraries and integrations, etc that all do the same thing and you have to pick one which pisses off everyone who prefers one of the other options.

I have a general roadmap (it isn’t public but I can share it if someone is interested) that outlines, from my perspective, what needs to be done to modernize the *nix support. Parts of it are already done such as the dbus-glib dependency removal. Others are in progress such as EGL and QT6.

At this point I’d rather implement things that benefit everyone without me being questioned like improving CSS/JS support. Hopefully people won’t question “this website was broken. I fixed it” but at this point even that wouldn’t surprise me.

Apologies for my outburst and language earlier. I was speaking out of anger. Things like this are a massive reason as to why I decided to do that eUXP fork (I have no involvement with that project anymore for clarification).

[athenian200]

I’m going to keep working on it slowly, but Linux/*nix improvements are going to be bumped much lower in my priority list going forward if people are going to constantly complain along the way.

One thing I’ve come to appreciate after switching to MacOS on my laptop is that you only have one target. One toolkit. One OS configuration. Same with Windows. On Linux/BSD/etc you have a ton of toolkits, daemons, system libraries and integrations, etc that all do the same thing and you have to pick one which pisses off everyone who prefers one of the other options.

Glad to hear that, you worked hard on Qt support already and it seems like a waste to throw it away. I'd be willing to help test it and maybe even contribute some code, but I can't do it alone because I don't daily drive Linux.

Completely agree with you there, it's part of why I just never came around to daily driving Linux even though I thought it was fun to play with. The trick I've learned is to just move forward with what I think is useful and not listen too much to user input. Don't get me wrong, I might listen to user input on a variety of options I think make sense, and then go with the most popular of them, and then implement that option in my way even if it's not their taste. Then just expect backlash. I mean, if we only did things all the users were happy with, we would never get anything done. The fact is, anything that gets done does mean angering some users while making others happy.

Apologies for my outburst and language earlier. I was speaking out of anger. Things like this are a massive reason as to why I decided to do that eUXP fork (I have no involvement with that project anymore for clarification).

It's okay, I understand the general community can be a bit much. Maybe more of these discussions about moving things forward should take place on the Gitea server rather than on the open forum... so that way the discussion mostly takes place among people who actually have the skills to contribute, or want to talk about build issues or regressions that are actionable. Just saying, it's an option...

And while I've never created my own fork of UXP (at least not since my first encounter with the project where I thought I would have to do that to add SunOS support), what I have done before is actually keep my changes under wraps until the thing I want to do is mostly done. Because I worry if they see it before it's 99% done, they'll jump to conclusions, speculate, argue about direction, lead things off course, etc. Whereas if they see it in nearly complete form, they'll be more likely to suggest minor tweaks and improvements rather than push for something to be radically different. The difference is I just keep it on my own computer and move my changes around between machines with a git repo on a USB drive when I don't want people to either get their hopes up if I fail, or else try to be a backseat driver before I get very far in the process.

Anyway, I guess we can get back on topic of the Qt port itself now. That may have been a digression, but I think it was needed.

[solitude]

Off-topic:
I've never coded before, but If I get free time to tinker, in following weeks maybe, I might look into how this Qt stuff works and try to improve the port. Don't quote me tho :P

[gabrgv]

Off-topic:

Off-topic:
I have a general roadmap (it isn’t public but I can share it if someone is interested)...

I'm interested, if you don't mind telling.

[JayByrd]

I prefer GTK2 to GTK3, and Qt would be just fine with me.

Personally, I appreciate having more options at compile time. My question is: are we proposing to add Qt support, or to replace GTK with Qt? (...and, again, I would be fine either way, I'm just looking for clarification.)

Off-topic:
Off-topic addendum:
I don't want to sound too preachy here, but I feel you guys might suffer far fewer headaches on the Linux side of PM/UXP, if you'd go Slack.
Slackware -current ships w/ GTK 1, 2, 3, & 4 and Qt 5 & 6, plus a default install includes a full development suite with everything from gnucobol to ninja, including both python 2 & 3, with gcc version 15.2. (It also has Qt Designer and Glade standard.)

...just sayin'... Carry on.

[Night Wing]

Off-topic:
Off-topic addendum:
I don't want to sound too preachy here, but I feel you guys might suffer far fewer headaches on the Linux side of PM/UXP, if you'd go Slack.
Slackware -current ships w/ GTK 1, 2, 3, & 4 and Qt 5 & 6, plus a default install includes a full development suite with everything from gnucobol to ninja, including both python 2 & 3, with gcc version 15.2. (It also has Qt Designer and Glade standard.)

...just sayin'... Carry on.

Off-topic:
I use GTK2 for linux Pale Moon.

I am not a power user. Just someone is between a power user and a non-technical user. When I tried Slackware about 6 months ago, it did not appeal to me. Six things which I did not like.

1) There is no graphical installer
2) No automatic package management
3) Fewer user friendly tools.
4) Installing a desktop environment is not easy
5) Multimedia support or installing drivers takes extra steps which can be daunting
6) And I am not a fan of heavy Terminal usage

Some people like minimalism, but I am not one of them. As they say; "To Each, Their Own".

[andyprough]

Off-topic:
Slackware -current ships w/ GTK 1, 2, 3, & 4 and Qt 5 & 6, plus a default install includes a full development suite with everything from gnucobol to ninja, including both python 2 & 3, with gcc version 15.2. (It also has Qt Designer and Glade standard.)

Sounds pretty cool, I'll have to check it out! Did not know that about Slackware.

[mr tribute]

Off-topic:
Slackware -current ships w/ GTK 1, 2, 3, & 4 and Qt 5 & 6, plus a default install includes a full development suite with everything from gnucobol to ninja, including both python 2 & 3, with gcc version 15.2. (It also has Qt Designer and Glade standard.)

Sounds pretty cool, I'll have to check it out! Did not know that about Slackware.

There is also the Arch AUR repo that has all those toolkits plus Qt4 and basically all forks of gtk3 etc.
I recommend gtk3-classic for those who want gtk3 to be more similar to gtk2.
You install at your own risk from Arch AUR so check package definition/manifest and source code.
Btw, I don't use Arch.

[Drugwash]

My question is: are we proposing to add Qt support, or to replace GTK with Qt?

As it has been stated here before, the idea is to ADD Qt as an alternative for future-proofing, while Gtk will stay both as Gtk2 - even if only for self-building, at some point - and Gtk3.

And to make it clear about he following statement for any readers:
Slackware -current ships w/ GTK 1, 2, 3, & 4 and Qt 5 & 6, plus a default install includes a full development suite with everything from gnucobol to ninja, including both python 2 & 3, with gcc version 15.2. (It also has Qt Designer and Glade standard.)

I believe this was meant for the PM developers in the idea that a Slackware setup would allow them to build and test any and all Gtk and Qt versions of Pale Moon before release. At least that's how I saw it, and my apologies if it wasn't right.