You are not logged in.
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)
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )
Offline
$XDG_CURRENT_DESKTOP is set as XFCE in my current BL-on-a-stick system.
“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.
Offline
@ HoaS,
Does that not strike you as being a lie?
We are using OPENBOX, right?
What version of bl is it that you installed?
Offline
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
Perhaps @hhh & @twoion can elaborate further.
Last edited by Head_on_a_Stick (2016-02-03 09:05:45)
“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII., 18.
Offline
@hhh
Glad you like it
There is nothing like a good discussion to bring out all the pros and cons in the open.
Offline
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?
Offline
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.
Offline
^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).
Offline
-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.
Offline
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...
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )
Offline
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?
Offline
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.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )
Offline
^and not forgetting the possibility of light-locker issues without XDG_CURRENT_DESKTOP being set.
( https://bugs.launchpad.net/ubuntu/+sour … ug/1212408 )
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )
Offline
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.
Offline
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.
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".
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )
Offline
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?
Offline
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.
Real Men Use Linux
Offline
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
Be Excellent to Each Other...
The Bunsenlabs Lithium Desktop » Here
FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt «» BunsenLabs on DeviantArt
Offline
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)
Please use CODE tags for code.
Search youtube without a browser: repo | thread
BL quote proposals to this thread please.
my repos / my repos
Offline
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.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), idle Twitterings and GitStuff )
Offline