LXQt Session Settings: Add a way to Ignore Default Environment Variables Per User - or unset them

[Myrddin-Wyllt]

LXQt has a system-wide session.conf which is located in Arch at /usr/share/lxqt/session.conf. This provides some defaults for LXQt, including default environment variables. These variables should be overridden on a per-user basis (i.e., as with most other Linux programs) in ~/.config/lxqt/session.conf. The opposite seems to be occurring (i.e., system-wide session.conf overrides per-user session.conf).

Setting environment variables in LXQt Session Settings should override system-wide defaults as expected.

System-wide default environment variables override per-user session.conf if the lines are blank in the per-user session.conf.

Change the precedence/load order in Session settings in case lines are blank (i.e., add a way to ignore system default environment variables when deleted from per-user session.conf)

This issue was discovered when trying to get gtk3-mushrooms working with LXQt.
lah7/gtk3-classic#15 (comment)

[agaida]

please provide your configs and the not working environment variables.

[agaida]

just tested - works fine for me:

% grep GTK /usr/share/lxqt/session.conf 
GTK_CSD=0
GTK_OVERLAY_SCROLLING=0
---
% grep GTK $HOME/.config/lxqt/session.conf
GTK_CSD=
GTK_OVERLAY_SCROLLING=
---
% env | grep GTK                                                                                                                                                                             
GTK_CSD=
GTK_MODULES=gail:atk-bridge
GTK_OVERLAY_SCROLLING=

q.e.d.

[Myrddin-Wyllt]

Steps to reproduce behavior:

1. Open LXQt Session Settings
2. Delete GTK_CSD and GTK_OVERLAY_SCROLLING
3. Restart session (logout/in or reboot)
4. Wonder why GTK_CSD and GTK_OVERLAY_SCROLLING are still set

~ $ grep GTK /usr/share/lxqt/session.conf 
GTK_CSD=0
GTK_OVERLAY_SCROLLING=0
---
~ $ grep GTK $HOME/.config/lxqt/session.conf 
---
~ $ env | grep GTK
GTK_CSD=0
GTK_MODULES=canberra-gtk-module
GTK_OVERLAY_SCROLLING=0

The problem here is that setting these variables at all causes Client Side Decorations to be enabled in gtk3-mushrooms. I went about removing GTK_CSD and GTK_OVERLAY_SCROLLING lines in /usr/share/lxqt/session.conf as shown below:

[General]
window_manager=openbox
leave_confirmation=true

[Environment]

[Mouse]
cursor_size=18
cursor_theme=whiteglass
acc_factor=20
acc_threshold=10
left_handed=false

[Keyboard]
delay=500
interval=30
beep=false

[Font]
antialias=true
hinting=true
dpi=96

Notice the empty [Environment] section.

After this alteration, my environment looks like thus:

~ $ grep GTK /usr/share/lxqt/session.conf 
~ $ grep GTK $HOME/.config/lxqt/session.conf 
~ $ env | grep GTK
GTK_MODULES=canberra-gtk-module

Due to this, gtk3-mushrooms works now without issue; but this has revealed that the system-wide configuration is overriding per-user configuration for session.conf for environment variables when removed by user (i.e., I'd appreciate a way to ignore these somehow without editing /usr/share/lxqt/session.conf)

[agaida]

and i see no problem in the behaviour - that is exactly what xdg should do - reading configurations in different levels:

0: /usr/share/ - not used
1: /usr/share/lxqt - used (in your case the GTK config is read and valid)
2: /etc/xdg/lxqt - not used
3: /etc/lxqt - not used
4: /$HOME/.config/lxqt/ - used (in your case: you deleted the overrides, so what?)

More verbose: you deleted the GTK* lines so the valid settings from level 1 are valid. in my example i set GTK_CSD to an empty value. The only thing the application can't do right now is to unset some things - also to be expected.

[agaida]

if 0 is really needed to activate and 1 to force all the things - try to blank them '' or -1 might work

EDIT: It might be worth it for the session to implement a mechanism to unset some enviromental variables (at all levels) so i reopen the issue

[agaida]

@tsujan @palinek @luis-pereira @yan12125 - what do you think?

[agaida]

Reference is: lah7/gtk3-classic#15

and Tomasz is very clear about the need of unset GTK_CSD - so a possible solution would be in session.conf:

[Environment]
GTK_CSD=unset
GTK_OVERLAY_SCROLLING=unset

or another value instead of unset. In this case the session should unset the defined environment variable.

[tsujan]

@agaida I didn't follow the discussion but QSettings first searches in the user config file for a key-value pair and only if it isn't found, reads it from the global config file(s). KEY= means a value of false, 0, or empty string depending on whether KEY is a boolen, an integer or a string.

[tsujan]

In other words, if there is a line KEY= in the user config file, the value of KEY won't be read from the global config file but is set to false, 0 , or QString().

[agaida]

@tsujan - and we might have a problem with that. If we read something from the [Environment] section we can only set a environmental variable - but not unset it. That might be a major difference in some cases.

[tsujan]

To unset an environment variable, the code needs to support unsetting.

[agaida]

Right - and i hereby suggest to implement it, hopefully it is not rocket science

[tsujan]

Should be very easy.

[tsujan]

@agaida Since I'm not familiar with the code, I just make a suggestion here. Try changing the function lxqt_setenv to:

void lxqt_setenv(const char *env, const QByteArray &value)
{
    wordexp_t p;
    wordexp(value.constData(), &p, 0);
    if (p.we_wordc == 1)
    {

        qCDebug(SESSION) << "Environment variable" << env << "=" << p.we_wordv[0];
        if (p.we_wordv[0])
            qputenv(env, p.we_wordv[0]);
        else
            qunsetenv(env);
    }
    else
    {
        qCWarning(SESSION) << "Error expanding environment variable" << env << "=" << value;
        if (!value.isEmpty())
            qputenv(env, value);
        else
            qunsetenv(env);
    }
     wordfree(&p);
}

Then, if the variable value is empty, it should be unset.

[agaida]

Thats exactly the point - we talk about shells - in some cases it is only asked if the variable is set - the value is not important. Thats why i asked explicitly how to unset a certain environmental variable.

[tsujan]

Qt doc says about qputenv:

Calling qputenv with an empty value removes the environment variable on Windows, and makes it set (but empty) on Unix. Prefer using qunsetenv() for fully portable behavior.

[agaida]

right - i was only thinking about the distinction of setting a value to 0 or blank and unset a variable - we should make a difference i guess.

[tsujan]

What would be its use? An example where that distinction is necessary?

[tsujan]

if 0 is really needed to activate and 1 to force all the things - try to blank them '' or -1 might work

Is that the example?

[tsujan]

The problem here is that setting these variables at all causes Client Side Decorations to be enabled in gtk3-mushrooms.

GTK+ doc explicitly says:

GTK_CSD. The default value of this environment variable is 1. If changed to 0, this disables the default use of client-side decorations on GTK+ windows, thus making the window manager responsible for drawing the decorations of windows that do not have a custom titlebar widget. CSD is always used for windows with a custom titlebar widget set, as the WM should not draw another titlebar or other decorations around the custom one.

So, gtk3-mushrooms should have a bug.

I don't think unsetting an EV could have any use. This can be closed again, IMO.

[tsujan]

OK, https://github.com/TomaszGasior/gtk3-mushrooms/blob/master/README.md#client-side-decorations-only-on-xorg says:

You can enable CSDs by setting GTK_CSD=0 environment variable

That's the opposite of what GTK doc says; hence the problem. I really don't think it's our problem.

[agaida]

it a problem in general - i have seen such things in the past a few times - and it wasn't about some X things like gtk-mushroom. Have seen it in daemons a lot. So i would prefer if we really could unset things - like in $foo=unset -> unset foo

Edit: This bug was only a reminder.

[tsujan]

gtk-mushroom wants to be nonstandard. So, such things should happen with it.

IMO, a good app should NOT react to an EV in this way. That doesn't mean gtk-mushroom is bad but when you break a standard, there will be consequences.

[agaida]

As i said - i stumbled over these things a few times in the past ten years - and i guess it will not hurt if we can implement it without pain - setting things to blank is allways possible and ever was - so no changes needed. But making it possible to unset things would be nice.

[tsujan]

i stumbled over these things a few time in the past ten years

That may mean that you encountered bugs in apps. I see no reason to add workarounds for certain bugs.

[tsujan]

setting things to blank is allways possible

Setting an EV to blank does set it to blank ;)

[agaida]

yes - and an EV can be set or unset - thats why the unset exists - isset(foo) is legit and was/is often used.

[tsujan]

Theoretically, a checkbox could be added in front of every EV and if its unchecked, that EV would be unset. If the box is checked but the value is blank, the EV would be set to blank. Just a plan -- not for myself though ;)

[agaida]

A box would be fine to - and when we are on it we should remove the
TERM=qterminal line somewhere