I don't want to duplicate all environment variables.

In normal circumstances, it should not be necessary to set any environment variables to run GTK+ applications.

> I don't want to duplicate all environment variables.

We came at the same conclusion, right now we are patching only the following variables to use GTK3 variant when available:

- GTK_IM_MODULE_FILE
- GTK_THEME
- GTK_DATA_PREFIX
- GTK_PATH
- GTK_IM_MODULE
- GTK_EXE_PREFIX

I cannot speak for all the variables in the list, but in the case of `GTK_IM_MODULE_FILE`, it is used by both GTK+2 and GTK+3, can point only to a single file and that file can refer to only one version of GTK.
Making it impossible to use `GTK_IM_MODULE_FILE` when using both GTK+2 and GTK+3.

Implementing this will increase flexibility and and doesn't introduce much complexity.

> In normal circumstances, it should not be necessary to set any environment variables to run GTK+ applications.

I agree, but some distributions like NixOS use immutable package files making these environment variables very useful.

Created attachment 325350 [details] [review]
Newer patch, patching fewer variables

This patch is patching only the following variables to use GTK3 variant when available:

- GTK_IM_MODULE_FILE
- GTK_THEME
- GTK_DATA_PREFIX
- GTK_PATH
- GTK_IM_MODULE
- GTK_EXE_PREFIX

My comment still stands... you shouldn't set any of these, but use proper settings to set up the input method frame work and theme, and leave the path, data and exe prefix alone.

To add additional clarification, Nix(OS) is a somewhat special case:

1. On one hand, we have NixOS the distribution built on Nix, which doesn't have regular /usr, /bin etc. at all. Instead we have `/run/current-system/sw` which is a symlink to a directory in an immutable store. So we need GTK to look inside it for themes and other resources.

2. On the other hand, we have Nix the package manager which provides GTK and GTK applications as packages and can be installed on conventional FHS-compliant Linux distribution. On it, GTK needs to look for resources in standard paths. That's why we can't just patch GTK to have NixOS-specific paths by default -- it would break packages on non-NixOS.

So, we get around this by setting those environment variables on NixOS -- but this is problematic when GTK2 and GTK3 are both used because of this problem.

However, I'm much more familiar with Nix(OS) than GTK -- I might be missing the obvious or misunderstanding something.

Sound like a problem you've made for yourself.

Well, we have reasons to do things this way (some explanation is available at https://nixos.org/nixos/about.html in "How does NixOS work?" section). If you conclude that our use case is not supported, feel free to close this bug I guess.

> Sound like a problem you've made for yourself.

The problem can be separated in 2 points, and both don't originate from Nix:

A/ gtk using libdir as a default cache file location [1]
One could ask "Is libdir a correct place for a cache file?" and argue that this goes against the reproducible build action [2] in which many distributions like Debian, Fedora, Archlinux and FreeBSD participate.
(How can you have a reproducible build if one file in the package is mutable and totally depends on other packages installed in the system and should be regenerated everytime a new input method is installed or removed)

B/ gtk2 and gtk3 use the same GTK_IM_MODULE_FILE that are incompatible. 
From gnome documentation: [3]

> Note that this environment variable is read by GTK+ 2.x too, which makes it unsuitable for setting it system-wide (or session-wide), since doing so will cause either GTK+ 2.x applications or GTK+ 3 applications to see the wrong list of IM modules. 


So we are in a situation where the default place of `immodules.cache` is bad practice (and impossible in Nix and Guix) because builds should be deterministic (A), and also we shouldn't use `GTK_IM_MODULE_FILE` because you say so, and if ever we use it it will generate incompatibilities between gtk2 and gtk3 because it is using the same variable name(B).

So what can we do? Using GTK3 versions of environment variables was one (simple & dirty) approach, but maybe putting the mutable cache files in a more fitting place as `~/.cache/` like fontconfig does and using different cache names for gtk2/3 would be better? Of course that would involve much more work.

As a last note, there is a "Running GTK+ Applications" [3] official documentation page that explains all the environment variables and their usage and doesn't mention that they shouldn't be used, so "you shouldn't set any of these (environment variables)" is a hard to understand position from a user standing point.

[1] https://developer.gnome.org/gtk3/stable/gtk-query-immodules-3.0.html
[2] https://reproducible-builds.org/who/
[3] https://developer.gnome.org/gtk3/stable/gtk-running.html

(In reply to eric.sagnes from comment #8)

> 
> So we are in a situation where the default place of `immodules.cache` is bad
> practice (and impossible in Nix and Guix) because builds should be
> deterministic (A), and also we shouldn't use `GTK_IM_MODULE_FILE` because
> you say so, and if ever we use it it will generate incompatibilities between
> gtk2 and gtk3 because it is using the same variable name(B).
> 
> So what can we do? Using GTK3 versions of environment variables was one
> (simple & dirty) approach, but maybe putting the mutable cache files in a
> more fitting place as `~/.cache/` like fontconfig does and using different
> cache names for gtk2/3 would be better? Of course that would involve much
> more work.

I would be much more interested in patches that fix cache file locations like that or just make gtk work without the cache than I am in adding extra environment variables as a 'quick fix'.

The long term vision for this is that we want to move away from loading modules for these things altogether. GTK+ should just use the preferred input method framework of the platform it is running on (for Linux, that would be ibus), not let the use switch between dozens of unmaintained and half-working alternatives.

> As a last note, there is a "Running GTK+ Applications" [3] official
> documentation page that explains all the environment variables and their
> usage and doesn't mention that they shouldn't be used, so "you shouldn't set
> any of these (environment variables)" is a hard to understand position from
> a user standing point.

We strive to document all our interfaces - if nothing else, you need to know what variables affect your application while debugging something. Being documented by itself does not imply "you should use this". I'll try to add some stronger wording to this to make it clear that you are not supposed to set any of these to make GTK+ work .

Thanks for the detailed answer, I understand your position and how the approach of patching deprecated environment variables is not the best choice.

> The long term vision for this is that we want to move away from loading modules for these things altogether. GTK+ should just use the preferred input method framework of the platform it is running on (for Linux, that would be ibus), not let the use switch between dozens of unmaintained and half-working alternatives.

That totally make sense, and I can't wait to see that happen.
So as the NixOS use case is quite uncommon, I guess the best we can do for now to have working input methods is to patch our version until these functionalities are available.

Review of attachment 325350 [details] [review]:

just to get this off the unreviewed patches list

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new