Pale Moon and GTK

[mr tribute]

So, mostly because I'm bored I ask this boring question. My preferred desktop Xfce has had its first GTK3 release. Are there plans to port Pale Moon to GTK3? I personally think GTK3 is a letdown, but you know it's the FUTURE... That being said GTK2 applications run fine in GTK3 environments. I won't complain if Pale Moon stays GTK2, but other users might when GTK2 starts getting phased out from distros. It can happen as early as Ubuntu 20.04 - correct me if I'm wrong about this.

Symbolic icons rant:
I don't understand the "symbolic icons" trend. The purpose of icons is to be easily distinguishable. If they are made monochome and uniform, what's the point of even having them? Firefox looks like crap and doesn't adopt the icon theme. OK, if Firefox devs like "minimalism" so be it, but not adopting the icon theme is a sin on Linux. I wonder why GTK devs created a special category for symbolic icons instead of just adopting whatever theme in use?

[Moonchild]

Symbolic icons rant:
... I wonder why GTK devs created a special category for symbolic icons instead of just adopting whatever theme in use?

2 words: Brand Identity.

[Isengrim]

Are there plans to port Pale Moon to GTK3?

Not officially, IIRC. You can build it yourself with GTK3 if you're so inclined, though there are a few issues with GTK 3.20 and up breaking styles on certain controls.

[bgstack15]

I agree with mr tribute's points of view entirely. I find nothing wrong with GTK2, but yes, the future appears to be GTK3.

It appears that people with our point of view do not run the show in distros or development. I know that I don't have the chops for that sort of thing, so I will learn to adapt to the whims of the drivers of change, whether for better or worse. Except for GNOME devs; I'll stick to Xfce.

[Isengrim]

the future appears to be GTK3.

And soon to be GTK 4: the current release of 3.24 is supposedly the last release of the GTK 3 family.

[Moonchild]

So will GTK 4 be as radically different as 3? Are they going for the whole square and super flat thing now?

[vannilla]

So will GTK 4 be as radically different as 3? Are they going for the whole square and super flat thing now?

According to some screenshots I found on the web, yes it's going to be like that.

[Moonchild]

Targeting the wrong audience then. If they are trying to mimic win 10, then they should realize that people who are fleeing from Win 10 don't want linux to look like it; and conversely those who like the look will likely stick to Windows.

[Isengrim]

That plus the constant breaking changes they seem to introduce every version... if only Firefox had maintain its Qt widget library. :/

[dinosaur]

I, for one, dislike GTK3 and wish to see PM keep a GTK2 UI, at the very least as a compile option.

As for GTK2 perennity, I don't see it disappearing any time soon. Hell, even GTK+ 1 is still available (albeit unmaintained)...

[New Tobin Paradigm]

In any event, we KNOW that distros are already busting GTK2 or more properly are not keeping perfectly functional for changes everywhere else including compilers and dependencies. As for Pale Moon and GTK.. It is my opinion that Pale Moon targeting GTK2 should continue indefinitely. HOWEVER, it is also my feeling that when it comes to specific package maintainers that the choice of GTK version should be consistent with the prevailing GTK version of the target distribution. For instance, Fedora packages should target GTK3 because GTK2 is not entirely stable anymore and affects stability of the application.

This is allowed for in the Pale Moon Redistribution terms. So let's not start a GTK2 vs GTK3 argument calling for one to be removed over the other. There is no reason both cannot remain forever.

NOW for general UXP development we should consider putting some attention on both getting GTK3 support tweaked for a target of the latest/last GTK3 version (3.24?) and start looking into GTK4 for the future. Again, I see no reason to drop GTK2 support or production of GTK2 builds for generic binaries.. HOWEVER, it might be wise to start producing a generic binary for GTK3 like BinOC does. That way in absence of a package for a specific distribution, those ultra-modern GTK3 predominate distros are not left with a substandard binary as their only choice.

[Isengrim]

NOW for general UXP development we should consider putting some attention on both getting GTK3 support tweaked for a target of the latest/last GTK3 version (3.24?) and start looking into GTK4 for the future.

Agreed. I'd love to help with this, but I do not know enough about GTK yet.

From what I've read, supporting GTK 3.24 will make it easier to support GTK 4. They're also promising a more stable API in the future, but that remains to be seen.

[New Tobin Paradigm]

We have some leeway but we must make a conserted effort.

Now it may be that last GTK3 will make it easier to support GTK4 but that might assume that we are going to comprise and/or drop GTK3. This would not be the case with us. I hope you or whomever contributes to this keeps that in mind.

Even if it means we have to clone and modify the widget code and evolve it up if we can't share code between versions reasonably.

[Moonchild]

HOWEVER, it might be wise to start producing a generic binary for GTK3 like BinOC does. That way in absence of a package for a specific distribution, those ultra-modern GTK3 predominate distros are not left with a substandard binary as their only choice.

I fully agree and have been thinking about this; also with Travis' situation enduring and having him with barely any time to devote to Pale Moon things, we might need to pass the Linux generic builds torch over to someone new; I don't particularly want to load more tasks on him at the moment (which doubling the Pale Moon builds for GTK versions would be).

[Night Wing]

I fully agree and have been thinking about this; also with Travis' situation enduring and having him with barely any time to devote to Pale Moon things, we might need to pass the Linux generic builds torch over to someone new; I don't particularly want to load more tasks on him at the moment (which doubling the Pale Moon builds for GTK versions would be).

Off-topic:
Reading the above just gave me a bad case of the "Monday Blues". Linux Pale Moon has been rock solid (for me) under Travis' watch.

[Moonchild]

Off-topic:
Just because someone else makes the builds doesn't suddenly mean they are going to be any less stable; the same code in the same environment will produce the same results, no matter who is bashing the keys for it -- it'll just need communication of the build environment, configuration and steps.

[New Tobin Paradigm]

Proper build environment (even just as a VM) as well as changes for AUS like enabling the substitute for %WIDGET_TOOLKIT% which I added in https://github.com/MoonchildProductions/UXP/commit/cb5d20deb7fed28887b9ea8edfad7792e59c1679. I added this specifically so that I don't have to do some crazy logic in BinOC applications which do produce both GTK2 and GTK3.

I could likely do the builds them selves as soon as I clean up my build VM. Even though I am also on restricted duty I still have to build Interlink anyway whenever Pale Moon releases. The AUS script and the primitive modified phoebus code for the linux site was coded by my self.. So I am the logical person to do this. What is an extra hour anyway to shove out a few builds.

FINDING TIME to do the prep work is my only real issue right now due to the aforementioned restricted duty due to demands on my focus. Likely won't be THIS release cycle but surely by the next one I will find a day to do the things.

As an additional note since I love constantly editing posts for about 10 minutes afterward... Even if I am not the one producing builds to help out I still need to do the rest of it.. As Moonchild stated, anyone who sets up the environment can build these builds... Khronosschoty for example could. Hell, Ascrod could. Just need the instructions for producing release builds as Travis does.