Set GTK 4 decoration layout

[jexposit]

The current attempt to show only the close button in the external application windows (see org.gnome.desktop.wm.preferences.gschema.override, button-layout property) is not working.

Instead, add a configuration file for GTK 4.

---

After spending quite a lot of time trying to make .gschema.override files work I gave up and decided to follow this approach.

I'm not sure if including this configuration file is acceptable or not.

Note that I had to set the environment variable XDG_CONFIG_DIRS (os.environ['XDG_CONFIG_DIRS'] = xdg_config_dirs) instead of settings it in util.startProgram(env_add=...). Otherwise, child processes, like Teclas, won't use the right paths.

I wonder if XDG_CONFIG_DIRS should be set in augmentEnv() instead. Waiting for feedback:

def augmentEnv():
    env = os.environ.copy()

    # Set XDG_CONFIG_DIRS so GTK 4 preferences are used
    datadir = os.environ.get('ANACONDA_DATADIR', '/usr/share/anaconda')
    xdg_config_dirs = datadir
    if 'XDG_CONFIG_DIRS' in os.environ:
        xdg_config_dirs = datadir + ':' + os.environ['XDG_CONFIG_DIRS']
    env.update({"XDG_CONFIG_DIRS": xdg_config_dirs})

    # FIXME: Remove the support for the ANA_INSTALL_PATH variable.
    env.update({"ANA_INSTALL_PATH": conf.target.system_root})
    env.update(_child_env)
    return env

As a side note, I also tried to follow the same approach with XDG_DATA_DIRS, but it didn't fix the issues.

[jexposit]

/build-image --boot.iso

[github-actions]

Images built based on commit 57a7109:

• boot.iso: success

Download the images from the bottom of the job status page.

[M4rtinK]

After spending quite a lot of time trying to make .gschema.override files work I gave up and decided to follow this approach.

I'm not sure if including this configuration file is acceptable or not.

If I understand it correctly, its stored in /usr/share/anaconda & won't be really loaded unless this folder is added to the correct environment variable, right ?

That way it should really only influence the installation environment on the boot.iso and perhaps applications started by the Anaconda process on Live images. That I think should be safe and potentially even desirable in other cases, say for the network-connection-editor, if it switches to GTK4 or if we end up launching more GTK4 apps.

[M4rtinK]

Looks good to me, thanks! :)

[jexposit]

Thanks for you review Martin.

If I understand it correctly, its stored in /usr/share/anaconda & won't be really loaded unless this folder is added to the correct environment variable, right ?

Yes. I added more details to the commit description so it is clear how this work.

Removing the "draft" tag, but I don't know if we should set the environment variable in augmentEnv() instead. Letting you decide on this one.

[M4rtinK]

/build-image --live

[github-actions]

Images built based on commit c6e72e6:

• Live: failure

Download the images from the bottom of the job status page.

[M4rtinK]

/build-image --live

[M4rtinK]

Just checking the boot.iso (as live image creation seems to have some issues right now) and all seems fine:

I've also checked some other "on top" cases, which are not GTK4 based, just in case.

A modal dialog.

The network connection editor (GTK3 ?).

Both look fine. :)

[github-actions]

Images built based on commit c6e72e6:

• Live: failure

Download the images from the bottom of the job status page.

[M4rtinK]

/build-image --boot.iso --live --webui

[github-actions]

Images built based on commit c6e72e6:

• boot.iso: success

• Live: success

Download the images from the bottom of the job status page.

[M4rtinK]

/build-image --live

[github-actions]

Images built based on commit c6e72e6:

• Live: success

Download the images from the bottom of the job status page.

[M4rtinK]

Removing the "draft" tag, but I don't know if we should set the environment variable in augmentEnv() instead. Letting you decide on this one.

Hmm, that could be also a possibility, but I think I like it better how it is co-located with other GUI/display related things, so I suggest we keep it as is. We can always switch to augmentEnv() if we find out the current way is causing issues, but it seems to work fine right now according to my testing.

Feel free to merge the PR. :)

[jexposit]

Thanks for your review Martin. Unfortunately, I can't merge it: