GNOME Bugzilla – Bug 542880
GNOME_DESKTOP_SESSION_ID not set anymore
Last modified: 2008-09-02 16:23:25 UTC
gnome-session 2.23.4.1 doesn't set GNOME_DESKTOP_SESSION_ID anymore. This variable is used by xdg-open 1.0.2 to determine if it is running under Gnome. Can you please put this back or give a hint which method should be used instead?
Just to note that this bug will also affect beagle since beagle-search sometimes uses xdg-open to open search results. Users who didnt have GNOME_DESKTOP_SESSION_ID set complained that all types of results opened by the browser by xdg-open.
This also affects Opera, which uses GNOME_DESKTOP_SESSION_ID to determine which file chooser to use.
confirming and bumping severity, it is breaking a lot of ISV scripts.
xdg-open should be fixed to look at GDMSESSION, I guess.
That wouldn't work, not everybody is using GDM, some are using kdm, xdm or startx.
xdg-open is just a collection of hacks. I don't see whats wrong with adding one more hack to it. From what I hear, it is broken with KDE 4 as well...
A more reliable check might be to look for org.gnome.SessionManager on the session bus? (IIRC, that would work for org.kde.SessionManager in KDE 4 as well.) And there's no real reason gnome-session couldn't just set GNOME_DESKTOP_SESSION_ID again. I think I just thought it wasn't being used for anything.
well, kde4 fixes has been pushed to xdg-open by Mandriva contributors :) And the point is there is some scripts outside (not only xdg-open), probably from ISV, which might depend on this variable. This is some kind of ABI breakage, so it would be best to ensure it is set, like with old gnome-session code.
compizconfig also rely on GNOME_DESKTOP_SESSION_ID to figure out which environment is running.
Any change of getting this back before the next tarball release, GNOME_DESKTOP_SESSION_ID is now effectively an interface that other programs depend on. The actual value it contains may be not that important, but it is important that it is returns consistently. This is a interface breakage!
Created attachment 117528 [details] [review] a patch to maintain a legacy interface
I attached a patch which avoided the use of libgnome and so based on the logical deduction of what is left of gnome-session. It is a most hacky patch but I hope someone will come up with a proper one :)
I've fixed this in another way. Frederic, Ghee: do you know if the actual value of this environment variable matters? If not, then I'll probably set it to "deprecated" or something like this... Oh well. Let's just go ahead and set it to "deprecated" now. I'll fix this if it's an issue.
I don't think it matters but setting it as "default" is probably a best shot, since it was the value usually set previously and there might be script out there checking it. BTW, setting it as deprecated mean there is now a another support way to check a process is in a GNOME session. Is it the dbus API ?
Vincent, so far there is one program that we know uses this, compiz. But it only check the presence of this environment variable, it doesn't check its value. So the way you fixed it should be okay for the case I knew. Frederic's question on supported way to known whether it is gnome-session is very useful.
Yeah, checking if there's something listening at the org.gnome.SessionManager interface (or whatever is the right way to say this in correct dbus language) is the right thing to do. Frederic: don't know. If someone was checking for "default", then it would have been broken with named sessions (that we were supposed to support). I'm fine with going back to "default" if people think it's necessary, though.
Opera doesn't care about the value of it - like you say it can be named.