Any Reason to Enable gconf in 2024?

[Basilisk-Dev]

I've been building Basilisk binaries with --disable-gconf on Linux systems since I took over the project. I've never once had a single user complain about any sort of issues with this configuration.

Is there any technical reason we should be enable it? GConf's last release was in 2013 and from what I can find on the internet it's been considered deprecated since at least 2015.

If there are no reasons to use GConf, would it not make sense to remove GConf support from the platform completely?

[athenian200]

I've been thinking that we should probably update it to GSettings (stumbled on some relevant Mozilla bugs at one point but never bookmarked them). I believe that GConf can still be used as the backend for GSettings on some platforms, though it's not ideal and really we should be replacing it with GSettings.

[mrnhmath]

There isn't. I was going to work on porting the relevant GSettings patches but somehow lost the BZ entries (swear I had them saved!)

[Pentium4User]

Is there any technical reason we should be enable it? GConf's last release was in 2013 and from what I can find on the internet it's been considered deprecated since at least 2015.

I tried building it on Debian Sid (13, trixie)and gconf isn't in the repo anymore.

[Basilisk-Dev]

I tried building it on Debian Sid (13, trixie)and gconf isn't in the repo anymore.

Same on OpenSuSE, both Tumbleweed and Leap.

[athenian200]

Actually, it looks like we may have a GSettings implementation already... some quick research in Bugzilla found that it was implemented in Firefox 6 already as part of preparations for GNOME 3.

https://xref.palemoon.org/goanna-centra ... ings&find=

The problem seems to be that, at least when we do GTK2 builds, they look for GConf and GIO. But as far as I know, GTK3 builds were never meant to depend on GConf or GIO in the first place:

https://xref.palemoon.org/goanna-centra ... re.in#2379

In fact, I'm finding more deprecated stuff like libgnomeui:

https://xref.palemoon.org/goanna-centra ... re.in#2472

So basically, we not only have GTK2, our GTK code is basically 100% wired up to work properly on the old GNOME 2 desktop as it existed back in 2010. This may be better approached as a meta-issue to modernize our GNOME support to at least the level expected by GNOME 3, Cinnamon, and MATE, I'm pretty sure the GNOME 40 series is out of the question.

The thing is, I would want to make sure our GSettings implemention works fine without GConf as-is before we stop building with GConf, and see what would be affected, etc. The issue is we've never really built withoug GConf before and have no idea what would break (if anything) on people's MATE, Cinnamon, or GNOME 3 desktops if we did. Mozilla didn't test this configuration until long after our fork point and may have addressed a few bugs during that time.

[Pentium4User]

I don't see a way to continue using gconf - current operating system development versions dropped it and that means in 1-2 years the most users will run those systems.

The GTK-3 builds work fine, and dropping GTK-2 should be possible.
I know this will annoy some users, but the question is how long it can be supported on current operating systems.

[athenian200]

I don't see a way to continue using gconf - current operating system development versions dropped it and that means in 1-2 years the most users will run those systems.

The GTK-3 builds work fine, and dropping GTK-2 should be possible.
I know this will annoy some users, but the question is how long it can be supported on current operating systems.

Well, I wasn't suggesting to continue using GConf indefinitely, what I'm suggesting is that we migrate to GSettings and test that everything works properly. To be clear, I'm not against removing GConf, just against removing it without any kind of testing or ensuring we migrate to GSettings properly. GTK2 itself isn't dependent on any of this, we can separate a lot of it out, but right now it's kind of a mess. So that is to say, we want to minimize the GNOME 2-specific dependencies, and focus on supporting stuff newer than GNOME 2 but older than GNOME 40.

As for dropping GTK2 itself, that will likely happen eventually, but it means NPAPI plugins will never work on Linux again, so we really want to push that out as far as possible. I've already introduced an option to build without NPAPI that will be unfortunately required on all Unix platforms except Mac once GTK2 is dropped.

The other issue is that a lot of our Linux users like to stay on older platforms for as long as they can, so stuff that wouldn't break on modern Linux might break for them. It's sort of like how a lot of our Windows users are still on Windows 7. Will we move on? Of course, but we have to bear in mind that we have the kind of users who won't move until forced, and thus our legacy support for older stuff has to go longer than most would consider reasonable. It also doesn't help that we don't have the manpower to implement newer stuff as fast as it's being adopted... there may even be a point where Linux has to be dropped altogether, all kinds of new stuff like Wayland is coming at us on there and things just change way too fast. I hope that's not the case, but it's hard to be optimistic.

[Pentium4User]

As for dropping GTK2 itself, that will likely happen eventually, but it means NPAPI plugins will never work on Linux again, so we really want to push that out as far as possible. I've already introduced an option to build without NPAPI that will be unfortunately required on all Unix platforms except Mac once GTK2 is dropped.

How is GTK-2 related to NPAPI?
Don't the GTK-3 builds support NPAPI?
I use them and they show the plugins section (I can't test it because I don't have any NPAPI plugins installed).

The other issue is that a lot of our Linux users like to stay on older platforms for as long as they can, so stuff that wouldn't break on modern Linux might break for them. It's sort of like how a lot of our Windows users are still on Windows 7.

Is that really the case and why?
Users have the choice of the desktop environment and privacy is possible with current Linux too.
Most distributions also run on old hardware, even if they run slowly.

I currently don't see reasonable arguments against using current Linux, maybe with X11 and an older desktop environment.

[athenian200]

How is GTK-2 related to NPAPI?
Don't the GTK-3 builds support NPAPI?
I use them and they show the plugins section (I can't test it because I don't have any NPAPI plugins installed).

They do. That is because we build the GTK3 builds against GTK3 for the main application, but still have the GTK2 libraries in there solely for plugin support, carefully separated from the main application itself. Because the Linux plugins are all, unfortunately, built against GTK2 (if they don't find GTK2, a handful of them can fall back to Xlib, which is even less desirable). This is not a problem for Mac and Windows, but it is a huge one on Linux.

So yes, Mozilla figured a clever trick to make it possible to run GTK2 plugins on a GTK3 version of the browser, with the main problem being that the GTK2 libraries (or at least their headers) are needed to make it work.

Building on a system without GTK2 at all means we have to disable NPAPI. But NPAPI itself should work on a GTK3 system as long as the Pale Moon binaries themselves were built on a system with GTK2 libraries, at least in theory. That is, GTK2 isn't a runtime requirement for NPAPI, but rather a build-time requirement.

Anyway, none of this is related to GConf, because that's related to integration with GNOME and its forks, not with the core toolkits.

To be perfectly clear, I only build Epyrus with GTK3, and it has never had an official GTK2 version. That annoys a lot of people, but I saw no point in introducing a GTK2 build to a new application. That actually puts me in a unique position to test disabling GConf on GTK3 builds, because it's very unlikely to affect anything there. Whereas it's a lot more unclear what would happen for people still on GTK2.

[Basilisk-Dev]

That actually puts me in a unique position to test disabling GConf on GTK3 builds, because it's very unlikely to affect anything there. Whereas it's a lot more unclear what would happen for people still on GTK2.

GConf is disabled in the GTK2 builds of Basilisk. I've never had anyone complain about it there either. NPAPI plugins seemed to work fine in my limited testing on GTK2 with GConf disabled.

[athenian200]

GConf is disabled in the GTK2 builds of Basilisk. I've never had anyone complain about it there either. NPAPI plugins seemed to work fine in my limited testing on GTK2 with GConf disabled.

Oh, I was talking more about integration with desktops like MATE, Cinnamon, and GNOME 3, and whether our GSettings implementation does what it's supposed to do with GConf disabled. GConf wouldn't have any bearing on NPAPI.

It might actually be hard to notice the kind of issues that GConf or GSettings not working properly would bring up, they'd be pretty subtle and only affect a subset of users... mostly things related to icons and desktop themes on GNOME and its forks. Basically, it's very simple... if our GSettings implementation works, then we don't need GConf at all. Otherwise, we need to fix any remaining issues in GSettings before removing GConf.

That said, I think experimenting with disabling GConf before ripping the code out is a logical thing to do, since it's already behind a build flag.

There's also other related stuff like GIO, libgnomeui, etc... just if we're tackling the GConf thing, there's a lot of other stuff we need to be looking into at the same time.

[Moonchild]

if our GSettings implementation works, then we don't need GConf at all. Otherwise, we need to fix any remaining issues in GSettings before removing GConf.

I think since it works on systems that don't have gconf at all, that indicates that our GSettings implementation works. The only issue would be installations that only have gconf, but I have no clue how much that is the case on the OSes we support.

[Pentium4User]

if our GSettings implementation works, then we don't need GConf at all. Otherwise, we need to fix any remaining issues in GSettings before removing GConf.

I think since it works on systems that don't have gconf at all, that indicates that our GSettings implementation works. The only issue would be installations that only have gconf, but I have no clue how much that is the case on the OSes we support.

Not everybody uses GNOME and won't notice problems related to theme settings of GNOME.
I think we should provide such builds and let people test it.

[athenian200]

I think since it works on systems that don't have gconf at all, that indicates that our GSettings implementation works. The only issue would be installations that only have gconf, but I have no clue how much that is the case on the OSes we support.

The browser would technically work without GConf or GSettings, if that's what you mean. In fact, it's likely a user on KDE or some desktop environment other than GNOME or one of its forks (like MATE or Cinnamon) wouldn't be able to tell the difference if both were ripped out.

I looked into the codebase to see what GConf and GSettings are used for, and... apparently the main use of both libraries is actually in the GNOME Shell Service to change the desktop wallpaper, as well as checking file associations before opening applications. So it's very possible no one would even notice if something were broken there unless they tried to change their desktop wallpaper on a GNOME-based desktop from within Pale Moon, or trying to open a downloaded file and see that it opens the correct program for that type of file.

So that's all we really have to check for A/B testing to see what the implications of removing GConf are. File associations and setting the desktop wallpaper. That's it. If those functions work on Linux with GConf disabled, we are in the clear.

[distantpluto]

...The browser would technically work without GConf or GSettings, if that's what you mean. In fact, it's likely a user on KDE or some desktop environment other than GNOME or one of its forks (like MATE or Cinnamon) wouldn't be able to tell the difference if both were ripped out...

As far as I'm aware, on Arch, everything GTK had gconf removed from the repos long ago. I haven't used any "desktop" (DE) for a very long time but I detest the look of GTK3 and 4 and cling to as many GTK2 incarnations as I can and even so, I have one single AUR package that has a dependency on gconf. If you install the official Gnome desktop (3 or 4) on Arch you won't get gconf. You will get dconf, the back end to gsettings.

[athenian200]

As far as I'm aware, on Arch, everything GTK had gconf removed from the repos long ago. I haven't used any "desktop" (DE) for a very long time but I detest the look of GTK3 and 4 and cling to as many GTK2 incarnations as I can and even so, I have one single AUR package that has a dependency on gconf. If you install the official Gnome desktop (3 or 4) on Arch you won't get gconf. You will get dconf, the back end to gsettings.

I mean, Arch isn't very representative of the type of environment I'm worried about here, that's bleeding edge... and a browser compiled on a system with a gconf library will work on a system that doesn't have it. If that weren't the case we would have stopped compiling against it long ago.

I think compiling against gconf is just because compiling against gconf became standard procedure for us ages ago, but it's the kind of thing people self-building it for distributions or other operating systems are free to turn off if they are sure their system doesn't use it. And once the decision was made that we needed it, we didn't really question it and figured there was no point in revisiting it until we dropped GTK2 entirely.

But anyway, I have an update. I tried disabling GConf in my .mozconfig, and then trying to set the desktop wallpaper and opening a text file on a GNOME 3 environment in Oracle Linux 7, which should be representative of the oldest systems we are targeting. First I tried it in Basilisk because Basilisk-Dev said it was fine there, and it was. Then I tried in Pale Moon. That also worked out okay. So as far as I can tell, we are not falling back on GConf on any system with GNOME 3 or later, and are in fact using GSettings when it comes to the shell service, which I think is the main place we were using it anyway.

Sorry I've been so meticulous about this, I just didn't want things to be subtly broken for a small number of people just to remove a build dependency from the default configuration. Especially since having it there doesn't really impact self-builders who are free to turn it off, and the official binaries run fine on systems without GConf anyway as-is.

[distantpluto]

I mean, Arch isn't very representative of the type of environment I'm worried about here, that's bleeding edge...

Arch just supplies the official upstream version, is there a version of Gnome 3 being used by any distro with gconf still integrated? I think Gnome themselves removed it 8+ years ago?

[athenian200]

Arch just supplies the official upstream version, is there a version of Gnome 3 being used by any distro with gconf still integrated? I think Gnome themselves removed it 8+ years ago?

Right, the concern really would have been older versions of MATE and Cinnamon at this point, who would have taken a little longer to catch up with GNOME itself. A lot of our users are on Cinnamon and use Mint, so that breaking is a potential issue.

But yeah, seeing that GSettings works is enough for me to be convinced that we don't need GConf, I was thinking we had yet to implement GSettings, or that our implementation must be in beta or something.

[mrnhmath]

From what I can remember, we rely on GConf for accessibility. They did move to GSettings after some time from our fork point.

Since I build suite with a11y enabled, I should be able to do some testing on this.