XDG_CURRENT_DESKTOP - screen locking and xdg-open

johnraff · 2016-01-19 08:03:40

This bug report, advocating that lightdm should set XDG_CURRENT_DESKTOP, suggests that not having that environment variable set might have caused locking issues with gnome-screensaver: https://bugs.launchpad.net/ubuntu/+sour … ug/1212408 Could it also have that effect with light-locker, and be causing the issues that some people havebeen having?

I haven't found such problems yet myself but I wonder if any of those who do could help us by:

1) posting a way to cause the issues to appear.
or
2) adding this line to ~/.config/openbox/environment

export XDG_CURRENT_DESKTOP=XFCE

rebooting and check if the behaviour changes at all?
(GNOME instead of XFCE should work too.)

---

BTW a related issue was the redundant call to bl-lock in bl-exit's suspend option. That has been fixed in version 8.6.2-1 of bunsen-utilities, which is now available for upgrading.

---
EDIT:

Another reason for setting XDG_CURRENT_DESKTOP=XFCE was to influence the behaviour of xdg-open so that it would use exo-open, which comes with Thunar. See this GitHub discussion: https://github.com/BunsenLabs/bunsen-configs/issues/30

---
EDIT:

The next 11 posts have been moved here from this thread: https://forums.bunsenlabs.org/viewtopic.php?id=1181
so do not necessarily follow on exactly from this first post.

Last edited by johnraff (2016-02-05 03:31:01)

Head_on_a_Stick · 2016-02-03 08:44:45

$XDG_CURRENT_DESKTOP is set as XFCE in my current BL-on-a-stick system.

See https://forums.bunsenlabs.org/viewtopic … 343#p17343

xaos52 · 2016-02-03 08:58:46

@ HoaS,
Does that not strike you as being a lie? yikes
We are using OPENBOX, right?

What version of bl is it that you installed?

Head_on_a_Stick · 2016-02-03 09:01:14

xaos52 wrote:

Does that not strike you as being a lie?

AFAIUI this was effected to increase compatibility with certain applications.

There is an issue raised about it, I think, give me a minute...

EDIT: It was installed from rc1 but has been fully updated.

EDIT2: I can't find the issue sad

Perhaps @hhh & @twoion can elaborate further.

Last edited by Head_on_a_Stick (2016-02-03 09:05:45)

xaos52 · 2016-02-03 09:06:03

@hhh
Glad you like it smile
There is nothing like a good discussion to bring out all the pros and cons in the open.

hhh · 2016-02-03 09:18:59

J'adore, monsieur.

>Perhaps @hhh & @twoion can elaborate further.

It's actually John who can speak on this iirc. @John, we just set this to Xfce to solve some minutia problem, right?

xaos52 · 2016-02-03 09:38:51

It's actually John who can speak on this iirc. @John, we just set this to Xfce to solve some minutia problem, right?

Oh I remember now seeing that go by. Something to do with the xdg startup mechanism and some jobs only showing for GNOME,KDE,XFCE...
Since OPENBOX was not in the list we trick the system by pretending we are XFCE.

hhh · 2016-02-03 09:41:36

^Yes, we decided that made sense since we're already running xfce4-power-manager and thunar and whatnot.

-edit- btw, transition of BL to MATE instead of Xfce is what I'm pushing, it's so solid with OB and they're doing great work developing it. Xfce on Debian is currently one guy, he needs some love (not from me at this time).

xaos52 · 2016-02-03 09:53:37

-edit- btw, transition of BL to MATE instead of Xfce is what I'm pushing, it's so solid with OB and they're doing great work developing it.

Will try that and let you know what I think of it.

johnraff · 2016-02-03 09:55:59

xaos52 wrote:

Something to do with the xdg startup mechanism and some jobs only showing for GNOME,KDE,XFCE...
Since OPENBOX was not in the list we trick the system by pretending we are XFCE.

Actually it wasn't that. In fact XDG_CURRENT_DESKTOP has no influence on /usr/lib/i386-linux-gnu/openbox-xdg-autostart, which takes an argument instead. (The argument OPENBOX is sent, but makes no difference from null atm. Maybe users can put it in custom .desktop files to influence startup behaviour?)

The reason that XDG_CURRENT_DESKTOP was set was to influence the behaviour of xdg-open. Yes it's a lie, but we thought the other XFCE apps we have onboard would'nt give us away to the authorities...

xaos52 · 2016-02-04 07:14:34

The reason that XDG_CURRENT_DESKTOP was set was to influence the behaviour of xdg-open. Yes it's a lie, but we thought the other XFCE apps we have onboard would'nt give us away to the authorities...

Been thinking about this.
How about creating a bl-xdg-open script as a wrapper to xdg-open, which sets the variable.

#!/bin/bash
export XDG_CURRENT_DESKTOP=XFCE
exec /usr/bin/xdg-open

That way you don't pollute (pardon the expression) your environment for a lot of processes that don't need XDG_CURRENT_DESKTOP. And it serves at the same time as documentation why we are setting the variable.

I mean, you still know it now while it is fresh in memeory, but will you still know it in a year, 2 years?

johnraff · 2016-02-04 08:23:36

xaos52 wrote:

The reason that XDG_CURRENT_DESKTOP was set was to influence the behaviour of xdg-open. Yes it's a lie, but we thought the other XFCE apps we have onboard would'nt give us away to the authorities...
Been thinking about this.
How about creating a bl-xdg-open script as a wrapper to xdg-open, which sets the variable.
#!/bin/bash
export XDG_CURRENT_DESKTOP=XFCE
exec /usr/bin/xdg-open
That way you don't pollute (pardon the expression) your environment for a lot of processes that don't need XDG_CURRENT_DESKTOP. And it serves at the same time as documentation why we are setting the variable.
I mean, you still know it now while it is fresh in memeory, but will you still know it in a year, 2 years?

We need @twoion's opinion on this.

johnraff · 2016-02-05 03:33:26

^and not forgetting the possibility of light-locker issues without XDG_CURRENT_DESKTOP being set.
( https://bugs.launchpad.net/ubuntu/+sour … ug/1212408 )

tknomanzr · 2016-02-05 03:41:03

My experience with light-locker is that once you fixed the redundant light-locker call, systemd-sleep was ending up stuck in the process list when coming back from resume, like it was failing to terminate correctly. I'd have to go back through the post history but am fairly certain that at least some of the reported light-locker issues were stemming from this. The most recent update to systemd on stable fixed the issue for me, so I feel like the light-locker issues should go away now.

I am sure that has nothing to do with XDG_CURRENT_DESKTOP except that it sounds to me like you feel it would be better set than not.

johnraff · 2016-02-05 03:51:41

tknomanzr wrote:

The most recent update to systemd on stable fixed the issue for me, so I feel like the light-locker issues should go away now.

That's very good news. smile

I am sure that has nothing to do with XDG_CURRENT_DESKTOP except that it sounds to me like you feel it would be better set than not.

Well, not necessarily...

There's the xdg-open issue we discussed on GitHub: https://github.com/BunsenLabs/bunsen-configs/issues/30

But OTOH there's xaos52's feeling that it "pollutes the environment".

hhh · 2019-05-01 05:34:46

I'm necromancing this long-dead thread because of a feature request I filed against the neofetch git...

https://github.com/dylanaraps/neofetch/issues/1232

As you can see, neofetch, and screenfetch, I think, pull the desktop from $XDG_CURRENT_DESKTOP, which is currently XFCE, hence "Working as intended".

Is there a way we can export BUNSENLABS_OPENBOX or similar instead without overriding why we did this in the first place?

DeepDayze · 2019-05-02 21:20:15

hhh wrote:

I'm necromancing this long-dead thread because of a feature request I filed against the neofetch git...
https://github.com/dylanaraps/neofetch/issues/1232
As you can see, neofetch, and screenfetch, I think, pull the desktop from $XDG_CURRENT_DESKTOP, which is currently XFCE, hence "Working as intended".
Is there a way we can export BUNSENLABS_OPENBOX or similar instead without overriding why we did this in the first place?

So that means if there are ANY XFCE components then it is registered as XFCE? That's a stretch.

damo · 2019-05-02 22:01:41

I hack the binfile! Change it to de="Openbox" in the relevant lines:

    # Format strings.
    case "$de" in
        "KDE_SESSION_VERSION"*) de="KDE${de/* = }" ;;
        *"xfce4"*) de="Xfce4" ;;
        *"xfce5"*) de="Xfce5" ;;
        *"xfce"*)  de="None" ;;
        *"mate"*)  de="MATE" ;;

        *"MUFFIN"* | "Cinnamon")
            de="$(cinnamon --version)"; de="${de:-Cinnamon}"
        ;;

        *"GNOME"*)
            de="$(gnome-shell --version)"
            de="${de/Shell }"
        ;;
    esac

ohnonot · 2019-05-04 09:33:09

DeepDayze wrote:

hhh wrote:
(...)
As you can see, neofetch, and screenfetch, I think, pull the desktop from $XDG_CURRENT_DESKTOP, which is currently XFCE, hence "Working as intended".
(...)
So that means if there are ANY XFCE components then it is registered as XFCE? That's a stretch.

no, DeepDayze, that is not at all the case.
bunsenlabs is deliberately setting that environment variable (see ~/.config/openbox/environment) because some of the XFCE components it uses require that to integrate better.

Last edited by ohnonot (2019-05-04 09:33:46)

johnraff · 2019-05-05 02:39:29

The reason that envvar was set, was to correct the behaviour of xdg-open, and possibly relieve some locking problems. It's a tricky issue though, and we ought to keep our eyes on it in case that hack becomes unnecessary.

#1 2016-01-19 08:03:40

XDG_CURRENT_DESKTOP - screen locking and xdg-open

#2 2016-02-03 08:44:45

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#3 2016-02-03 08:58:46

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#4 2016-02-03 09:01:14

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#5 2016-02-03 09:06:03

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#6 2016-02-03 09:18:59

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#7 2016-02-03 09:38:51

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#8 2016-02-03 09:41:36

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#9 2016-02-03 09:53:37

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#10 2016-02-03 09:55:59

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#11 2016-02-04 07:14:34

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#12 2016-02-04 08:23:36

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#13 2016-02-05 03:33:26

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#14 2016-02-05 03:41:03

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#15 2016-02-05 03:51:41

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#16 2019-05-01 05:34:46

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#17 2019-05-02 21:20:15

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#18 2019-05-02 22:01:41

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#19 2019-05-04 09:33:09

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

#20 2019-05-05 02:39:29

Re: XDG_CURRENT_DESKTOP - screen locking and xdg-open

Board footer