GNOME Bugzilla – Bug 655369
[PATCH] Set XDG_CURRENT_DESKTOP
Last modified: 2014-04-13 18:34:05 UTC
Created attachment 192700 [details] [review] Proposed patch In desktop environments that use gnome-session but don't use the XDG OnlyShowIn value of "GNOME" (i.e. "in Unity"), it is important to have XDG_CURRENT_DESKTOP set so that .desktop parsers can know how to interpret OnlyShowIn (e.g. bug 653440). A natural place to do this is gnome-session. Here's a patch that supports a new key in gnome-session .desktop files called DesktopName. If unset, it defaults to GNOME. That key's value will then be used to set XDG_CURRENT_DESKTOP.
Thats a bit over the top; our sessions already have names and it can be very appropriately found in the Name key. I don't think there's any need for duplicating this information.
Matthias, I don't understand your comment. 'Name' is no help at all here for the purpose of setting XDG_CURRENT_DESKTOP. 'Name' is human-readable, translatable, and different for each session. What's needed is a way to know what value to use for XDG_CURRENT_DESKTOP, which is machine-readable, not translated, and potentially the same for multiple sessions.
Well, I don't agree that having a machine-readable desktop identifier that is freely settable in this fashion is in our best interest. It is only going to become another extra thing that apps check, before looking for the features they actually want to use. Core parts of gnome like gnome-session, gnome-menus etc already know what desktop they belong to. If you are no longer shipping a gnome desktop, but still want to use gnome intrastructure for your competing offering, you can be expected to patch...
I'm sympathetic to the dangers that apps would substitute feature checks for desktop checks. But in the case of parsing OnlyShowIn, the feature check *is* a desktop check. You say it's not in GNOME's interest to have a desktop identifier, partly for fear apps will examine it. To me that implies that you view OnlyShowIn and NotShowIn as not in GNOME's interest. Is that a fair characterization and if so, could you expand on that? I understand that gnome-menus can default to assuming it's running in GNOME. But what about an LXDE application running on GNOME? It may need to know how to parse OnlyShowIn. Or a KDE app. There was a thread recently on d-d-l about KDE apps needing to look native when in GNOME and vice versa. XDG_CURRENT_DESKTOP is a piece of that puzzle. How else is a KDE app supposed to parse OnlyShowIn when running in GNOME (or XFCE etc)? Separately from the technical merits, you speak of Unity patching this in as if Ubuntu==Unity, which is not strictly true. Unity is an upstream of Ubuntu; it's not even shipped in all flavors of Ubuntu. If another distro wanted to include Unity, it could. You seem unhappy about another desktop shell using GNOME libraries. Or at least, unwilling to help it do so. I would like to collaborate; I think both GNOME Shell and Unity can benefit from more eyeballs and patches on GNOME libraries. Patches like this allow the two shells to cooperate.
Comment on attachment 192700 [details] [review] Proposed patch So right now, we have various bits of code looking at the org.gnome.SessionManager.SessionName property on the bus. I think that that's probably a better way to to go than environment variables. Environment variables always seem to bite us later (they can't be changed dynamically, they leak into processes we don't want them to leak into, they end up not getting set when we do want them set etc). Is looking at org.gnome.SessionManager.SessionName sufficient for you?
No. I see two problems with that. 1) User is running GNOME app "GFoo" in KDE. GFoo wants to check the environment, let's say to parse OnlyShowIn. Is "org.gnome.SessionManager.SessionName" likely to be available? Will it autostart something that can intelligently respond with "KDE"? 2) User is running KDE app "KBar" in GNOME. KBar wants to check the environment, let's say to parse OnlyShowIn. Are you expecting the KDE app to have support for "org.gnome.SessionManager.SessionName"? How would you expect that KDE app to implement OnlyShowIn for all environments? Hence XDG_CURRENT_DESKTOP as a standard.
Comment on attachment 192700 [details] [review] Proposed patch resetting status following comment 6
(In reply to comment #4) > I'm sympathetic to the dangers that apps would substitute feature checks for > desktop checks. But in the case of parsing OnlyShowIn, the feature check *is* > a desktop check. > > You say it's not in GNOME's interest to have a desktop identifier, partly for > fear apps will examine it. To me that implies that you view OnlyShowIn and > NotShowIn as not in GNOME's interest. Is that a fair characterization and if > so, could you expand on that? I don't think they are in any desktop's interest, or in the interest of app writers. OnlyShowIn only makes sense for things that are desktop components. Why would an application author restrict its app to run only in one environment ? NotShowIn just doesn't work, technically. It can theoretically be used to avoid conflicts like the 'System Settings' clash. But it means you have to patch the desktop file of app A if a conflicting app B appears in some other desktop. And then patch it again when another desktop grows a conflicting app. And then patch it again when a new desktop appears, etc... > I understand that gnome-menus can default to assuming it's running in GNOME. > But what about an LXDE application running on GNOME? It may need to know how > to parse OnlyShowIn. Or a KDE app. There was a thread recently on d-d-l about > KDE apps needing to look native when in GNOME and vice versa. > XDG_CURRENT_DESKTOP is a piece of that puzzle. How else is a KDE app supposed > to parse OnlyShowIn when running in GNOME (or XFCE etc)? I don't think apps are in the business of parsing and showing (desktop) menus. What kind of app is GFoo in your hypothetical example ? A menu editor ? There's an existing mechanism for toolkits to adjust their appearance according to the environment. Its called XSettings. It is not super extensive or extensible, but it is certainly more expressive than an env var. > > You seem unhappy about another desktop shell using GNOME libraries. Or at > least, unwilling to help it do so. I would like to collaborate; I think both > GNOME Shell and Unity can benefit from more eyeballs and patches on GNOME > libraries. Patches like this allow the two shells to cooperate. I'm mainly unhappy about enabling a style of app development that goes like desktop = getenv (...) if (desktop == "GNOME") { ...hack 1... } else if (desktop == "KDE") { ...hack 2... } else if (desktop == "Unity") { ...hack 3... } If you need to find out which desktop you are running in, there's ways to find out (earlier comments listed a few). I disagree that we should make it easy.
This has been resolved in gdm now, I believe