Proposal: $XDG_CURRENT_DESKTOP and the xdg-* commands
Hi Just earlier a user encountered an issue with xdg-settings, which would complain about an unknown desktop environment. Looked in the code and sure enough, it hard-checks for $XDG_CURRENT_DESKTOP and actually only implements kde, gnome and xfce. All other DEs are implemented with a dispatch_generic which would be suitable for any DE, really. Seeing as we have generic functions in all xdg-* commands, cant we merely check whether XDG_CURRENT_DESKTOP is set at all, and if it is (and we dont have a specific function for the DE in question), use the generic one? Writing a new DE shouldn't require changing these tools. As long as we don't do nonstandard stuff, they should just work. J. Leclanche ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Proposal: $XDG_CURRENT_DESKTOP and the xdg-* commands
On 06/01/2015 04:21 AM, Jerome Leclanche wrote: Hi Just earlier a user encountered an issue with xdg-settings, which would complain about an unknown desktop environment. Looked in the code and sure enough, it hard-checks for $XDG_CURRENT_DESKTOP and actually only implements kde, gnome and xfce. All other DEs are implemented with a dispatch_generic which would be suitable for any DE, really. Seeing as we have generic functions in all xdg-* commands, cant we merely check whether XDG_CURRENT_DESKTOP is set at all, and if it is (and we dont have a specific function for the DE in question), use the generic one? Writing a new DE shouldn't require changing these tools. As long as we don't do nonstandard stuff, they should just work. J. Leclanche I agree 100% here, I fixed similar issues with xdg-su and xdg-terminal under enlightenment, someone implemented xdg-open which added a check for the DE and because they didn't know they had to add actions to the others it broke everything else. xdg-su and xdg-terminal also just use xterm so they should just work regardless of DE. From what I saw when fixing enlightenment i'm pretty sure there is atleast 1 place where one of the other smaller DE's is still broken. Cheers Simon Lees ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG_CURRENT_DESKTOP
On 07/14/2011 11:36 AM, Michael Terry wrote: Hello! I've seen the idea of a XDG_CURRENT_DESKTOP environment variable tossed around a few times on this mailing list, but I don't see it in any spec. So XFCE and LXDE are already using it, xdg-utils wants to use it, and Unity provides a use case for its adoption in GNOME libraries. Looking at their code, XFCE and LXDE do different things when it's set to the empty string, but that would still match my suggested undefined behavior for that case. Any thoughts on the addition of a DesktopName key for XSession .desktop files? Is the next step to add my behavior proposal as a mini-spec on the XDG site or is this email thread sufficient to define use of the variable? (I don't think any changes have been proposed from the original email.) -mt ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG_CURRENT_DESKTOP
On Thu, 2011-07-14 at 11:36 -0400, Michael Terry wrote: Hello! I've seen the idea of a XDG_CURRENT_DESKTOP environment variable tossed around a few times on this mailing list, but I don't see it in any spec. Historically, most desktop file parsing libraries were tightly tied to a desktop and were able to assume which XDG desktop they were in (e.g. libgmenu assumes 'GNOME'). However in Unity, it uses most of the same libraries but still wants the ability to respect OnlyShowIn=Unity. So there's a need for those libraries to detect which desktop is running. The easiest/quickest way is to use an environment variable like XDG_CURRENT_DESKTOP. I have said this repeatedly, I will say it again: I don't think such 'desktop marking' is making anything better, really. It only makes the mess bigger by proliferating wierd and unmaintainable desktop-specific workarounds in many places. Applications should ideally not change their behavior depending on such markers. If they need to use services which may or may not be present, check for the proper dbus service names on the bus. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG_CURRENT_DESKTOP
On 07/19/2011 09:08 AM, Michael Terry wrote:
On 07/14/2011 11:36 AM, Michael Terry wrote:
Hello! I've seen the idea of a XDG_CURRENT_DESKTOP environment variable
tossed around a few times on this mailing list, but I don't see it in any
spec.
So XFCE and LXDE are already using it, xdg-utils wants to use it, and Unity
provides a use case for its adoption in GNOME libraries.
Looking at their code, XFCE and LXDE do different things when it's set to the
empty string, but that would still match my suggested undefined behavior
for that case.
Any thoughts on the addition of a DesktopName key for XSession .desktop
files?
Is the next step to add my behavior proposal as a mini-spec on the XDG site
or is this email thread sufficient to define use of the variable? (I don't
think any changes have been proposed from the original email.)
-mt
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Without loss of generality the Exec key can point to a script that sets any
environment variable one might want. There is no chance of convincing all DMs
to upgrade to do this based on a new key in the XSession file, nor is this
special purpose mechanism needed.
Speaking of which I have never come across any specification that documents
XSession files. The things I know are that they are in /usr/share/xsessions,
that Type=Application and Type=XSession are allowed, and that Exec works.
Apparently in KDM you can customize the search path. It would make sense if
Comment and Icon and TryExec worked as well but I do not know if those are
implemented in all the places that process these.
It would be good to have that written down as well.
As a general proposition {Not,Only}ShowIn is not proving to be a good idea.
Many of the problem reports we have in LXDE with menu items not showing up are
traced to OnlyShowIn=some other desktop.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG_CURRENT_DESKTOP
On 07/19/2011 09:38 AM, Marty Jack wrote:
Without loss of generality the Exec key can point to a script that sets any
environment variable one might want. There is no chance of convincing all DMs
to upgrade to do this based on a new key in the XSession file, nor is this
special purpose mechanism needed.
Ah, great point. So no need to worry about how the key gets set, either
the shell or the XSession file or someone can set it themselves without
involving the DMs.
As a general proposition {Not,Only}ShowIn is not proving to be a good idea.
Many of the problem reports we have in LXDE with menu items not showing up are
traced to OnlyShowIn=some other desktop.
Yeah, it's easily misused, e.g. I'm writing in GTK+, so I should add
OnlyShowIn=GNOME. But using the keys to partition the desktops is
still a strong use case, e.g. OnlyShowIn=KDE/NotShowIn=KDE in two
different desktop files for your app's two frontends.
-mt
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG_CURRENT_DESKTOP
PCMan wrote: Another user of this is xdg-utils. With this environment variable, all dirty code for desktop detection can be removed from xdg-utils. Yay, I'll be happy to incorporate this into xdg-utils, provided someone tells me the values to check for each DE. respond here, file a bug, mail me, whatever. -- rex ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
XDG_CURRENT_DESKTOP
Hello! I've seen the idea of a XDG_CURRENT_DESKTOP environment variable
tossed around a few times on this mailing list, but I don't see it in
any spec.
Historically, most desktop file parsing libraries were tightly tied to a
desktop and were able to assume which XDG desktop they were in (e.g.
libgmenu assumes 'GNOME').
However in Unity, it uses most of the same libraries but still wants the
ability to respect OnlyShowIn=Unity. So there's a need for those
libraries to detect which desktop is running. The easiest/quickest way
is to use an environment variable like XDG_CURRENT_DESKTOP.
I have some ideas on how such a variable might work:
== Reading ==
If XDG_CURRENT_DESKTOP is not set in the environment at all or if set to
the empty string, its value is undefined. This is for backwards
compatibility, so that parsing libraries can use whatever default
environment they want (as is the case now).
If set to a non-empty string, use that as the XDG desktop name ('GNOME',
'Unity', 'KDE', etc). Do not try to validate the value, as this makes
it difficult to add new desktops in the future.
It might be useful for debugging purposes to have a value that tells
libraries to ignore OnlyShowIn and NotShowIn and just show everything.
Maybe '*'? Not clear this is worth it.
== Writing ==
It seems easiest to have the DM set XDG_CURRENT_DESKTOP. How about
adding a new DesktopName field in the XSession desktop file, like so:
DesktopName=LXDE
If this field is not found in the XSession desktop file, the DM should
either not define the variable at all or set it to the empty string.
If this field is found in the XSession desktop file, the DM should set
XDG_CURRENT_DESKTOP to its value, again without any attempt at validation.
Thoughts?
-mt
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG_CURRENT_DESKTOP
On Thu, 2011-07-14 at 11:36 -0400, Michael Terry wrote: Hello! I've seen the idea of a XDG_CURRENT_DESKTOP environment variable tossed around a few times on this mailing list, but I don't see it in any spec. Historically, most desktop file parsing libraries were tightly tied to a desktop and were able to assume which XDG desktop they were in (e.g. libgmenu assumes 'GNOME'). However in Unity, it uses most of the same libraries but still wants the ability to respect OnlyShowIn=Unity. So there's a need for those libraries to detect which desktop is running. The easiest/quickest way is to use an environment variable like XDG_CURRENT_DESKTOP. I have some ideas on how such a variable might work: What's the use for this when you could add a set_desktop_name() function in the front-end that uses that library? Is it of any use apart from libgnome-menus? ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG_CURRENT_DESKTOP
On 07/14/2011 11:42 AM, Bastien Nocera wrote: What's the use for this when you could add a set_desktop_name() function in the front-end that uses that library? Is it of any use apart from libgnome-menus? Well, say there's an app FooBar that uses libgnome-menus. How does FooBar know which desktop it's in? -mt ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG_CURRENT_DESKTOP
On Thu, 2011-07-14 at 11:46 -0400, Michael Terry wrote: On 07/14/2011 11:42 AM, Bastien Nocera wrote: What's the use for this when you could add a set_desktop_name() function in the front-end that uses that library? Is it of any use apart from libgnome-menus? Well, say there's an app FooBar that uses libgnome-menus. How does FooBar know which desktop it's in? Application FooBar being? ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG_CURRENT_DESKTOP
On 07/14/2011 11:53 AM, Bastien Nocera wrote: Application FooBar being? Off the top of my head, gnome-session-properties, gnome-control-center, and alacarte are all cross-desktop apps that would have an interest in knowing the desktop name to control desktop file parsing. And those are just in GNOME. Other desktops may have similar apps that want to know. And some apps that aren't written yet may want to know. If libgnome-menu were to add such a set_desktop_name() function, it would only kick the problem up one layer. If that next layer happened to be the shell, then great, because shells *are* the desktop. But otherwise it's not much help. -mt ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG_CURRENT_DESKTOP
In Xfce XDG_CURRENT_DESKTOP is already used in a number of places as
an override for the default XFCE for {Only,Not}ShowIn. An example can
be found here [1]. The main purpose in our cases are mostly to make
the various parts of Xfce easier to use in other environments.
I think no library should ever assume it runs on a specific desktop,
but only provide the functions for an application to set this (in our
case garcon_set_environment).
Nick
[1]
http://git.xfce.org/xfce/xfce4-panel/tree/plugins/applicationsmenu/applicationsmenu.c#n216
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG_CURRENT_DESKTOP (was: Adding Unity to OnlyShowIn allowed values)
Thank you for mentioning this important issue again. I think the environment variable can be used in desktop entry spec for OnlyShowIn/NotShowIn and for determine default applications. In addition, the proposed desktop actions spec for file managers also needs a reliable way to determine current DE. Since desktop entry spec is used extensively nowadays, even in other specs such as menu and autostart specs, it's important to have a common, easy, and reliable way to check current DE. We already implemented support for this environment variable in our LXDE. When XDG_CURRENT_DESKTOP=GNOME, we can show applications with OnlyShowIn=GNOME rather than our apps in the application menu. Please consider adding this to desktop entry spec. On Sat, Mar 5, 2011 at 5:07 PM, Kevin Krammer kevin.kram...@gmx.at wrote: On Saturday, 2011-03-05, Ted Gould wrote: On Fri, 2011-03-04 at 18:37 -0500, Matthias Clasen wrote: On Wed, 2011-03-02 at 10:25 -0600, Ted Gould wrote: I haven't seen any objection, just questions to this. Final call? I have voiced my objection to the general idea of 'desktop switch' behaviour changes, but that's more of a complaint against XDG_CURRENT_DESKTOP than against OnlyShowIn=Unity I'm unsure why you object. It seem to be something that's generally useful for applications to know. For instance if they wanted to have a configuration check box for Show on Plasma Desktop or Show in Messaging Tray or something like that. They could make the strings more informative if the information was available. I think Matthias' point is that in order to do exactly that you'll need to look for the respective target functionality rather than assuming a one-to-one mapping of some identifier to a specific configuration. Basically all Free Software desktop workspaces consist of a setup of multiple processes, sometimes one process per task (IIRC that's how XFCE does it), sometimes two or more tasks combined into one process (e.g. GNOME Shell, Plasma desktop). One could argue to not care about non-default setups, e.g. using xfce-panel with a Nautlius desktop in a KDE session, but what about official deviations, e.g. GNOME 3 fallback on systems without 3D acceleration? Cheers, Kevin ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG_CURRENT_DESKTOP (was: Adding Unity to OnlyShowIn allowed values)
On Saturday, 2011-03-05, Ted Gould wrote: On Fri, 2011-03-04 at 18:37 -0500, Matthias Clasen wrote: On Wed, 2011-03-02 at 10:25 -0600, Ted Gould wrote: I haven't seen any objection, just questions to this. Final call? I have voiced my objection to the general idea of 'desktop switch' behaviour changes, but that's more of a complaint against XDG_CURRENT_DESKTOP than against OnlyShowIn=Unity I'm unsure why you object. It seem to be something that's generally useful for applications to know. For instance if they wanted to have a configuration check box for Show on Plasma Desktop or Show in Messaging Tray or something like that. They could make the strings more informative if the information was available. I think Matthias' point is that in order to do exactly that you'll need to look for the respective target functionality rather than assuming a one-to-one mapping of some identifier to a specific configuration. Basically all Free Software desktop workspaces consist of a setup of multiple processes, sometimes one process per task (IIRC that's how XFCE does it), sometimes two or more tasks combined into one process (e.g. GNOME Shell, Plasma desktop). One could argue to not care about non-default setups, e.g. using xfce-panel with a Nautlius desktop in a KDE session, but what about official deviations, e.g. GNOME 3 fallback on systems without 3D acceleration? Cheers, Kevin signature.asc Description: This is a digitally signed message part. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: XDG_CURRENT_DESKTOP (was: Adding Unity to OnlyShowIn allowed values)
On Fri, 2011-03-04 at 18:37 -0500, Matthias Clasen wrote: On Wed, 2011-03-02 at 10:25 -0600, Ted Gould wrote: I haven't seen any objection, just questions to this. Final call? I have voiced my objection to the general idea of 'desktop switch' behaviour changes, but that's more of a complaint against XDG_CURRENT_DESKTOP than against OnlyShowIn=Unity I'm unsure why you object. It seem to be something that's generally useful for applications to know. For instance if they wanted to have a configuration check box for Show on Plasma Desktop or Show in Messaging Tray or something like that. They could make the strings more informative if the information was available. --Ted signature.asc Description: This is a digitally signed message part ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
