Re: Cross platform URI schemes and notification area icons
On 07/24/2011 07:26 AM, Keith Poole wrote: Hey, Sorry if this has been covered before, but I couldn't find anything after a fair bit of research. I'm looking for a fairly distribution/DM-agnostic (eg: will work with Gnome/KDE/XFCE/etc) way of registering a new URI scheme such as abc://name?data and for creating a Notification Area icon. Any help or suggestions would be appreciated. Thanks in advance, -Keith ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg Well technically the IETF registers scheme names. However unless your application has industry wide impact they are not going to bother with you. I would suggest using whatever you like that seems unused and (up to some point pre-release) be prepared to change it if you later learn of a collision. It is hard to know without some more detail about the scope of what you are doing. As to notification area icons, in GTK there is GtkStatusIcon or GtkPlug; Qt has QSystemTrayIcon. If you were interested in the Ubuntu specific indicator applet mechanism, libindicator. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Cross platform URI schemes and notification area icons
On 07/24/2011 09:49 AM, Keith Poole wrote: Hey, Thanks for your response, however I was referring to registering it with the system, eg: application 'abc' starts and registers the scheme abc:// to run itself passing the URL as a parameter. Under Windows and Mac OS this is quite easy, but there are so many varieties of Linux and different desktop managers that I was hoping there might be some sort of cross-DM management tool, similar to, or as part of xdg-utils. Thanks -Keith On 24/07/2011, at 11:26 PM, Marty Jack marty...@comcast.net wrote: Unix-like systems tend to use MIME type as the input key for deriving an application that will handle a particular format. See xdg-mime and http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html There is no desktop independent registry for scheme such as you are describing. There are GNOME and KDE and browser specific ways of configuring it. On 07/24/2011 07:26 AM, Keith Poole wrote: Hey, Sorry if this has been covered before, but I couldn't find anything after a fair bit of research. I'm looking for a fairly distribution/DM-agnostic (eg: will work with Gnome/KDE/XFCE/etc) way of registering a new URI scheme such as abc://name?data and for creating a Notification Area icon. Any help or suggestions would be appreciated. Thanks in advance, -Keith ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg Well technically the IETF registers scheme names. However unless your application has industry wide impact they are not going to bother with you. I would suggest using whatever you like that seems unused and (up to some point pre-release) be prepared to change it if you later learn of a collision. It is hard to know without some more detail about the scope of what you are doing. As to notification area icons, in GTK there is GtkStatusIcon or GtkPlug; Qt has QSystemTrayIcon. If you were interested in the Ubuntu specific indicator applet mechanism, libindicator. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Cross platform URI schemes and notification area icons
On 07/24/2011 01:06 PM, Bastien Nocera wrote: On 24 Jul 2011, at 16:40, Marty Jack marty...@comcast.net wrote: On 07/24/2011 09:49 AM, Keith Poole wrote: Hey, Thanks for your response, however I was referring to registering it with the system, eg: application 'abc' starts and registers the scheme abc:// to run itself passing the URL as a parameter. Under Windows and Mac OS this is quite easy, but there are so many varieties of Linux and different desktop managers that I was hoping there might be some sort of cross-DM management tool, similar to, or as part of xdg-utils. Thanks -Keith On 24/07/2011, at 11:26 PM, Marty Jack marty...@comcast.net wrote: Unix-like systems tend to use MIME type as the input key for deriving an application that will handle a particular format. See xdg-mime and http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html There is no desktop independent registry for scheme such as you are describing. There are GNOME and KDE and browser specific ways of configuring it. There is, and it's in the document you linked. See URI scheme handlers. So there is. I had forgotten about that. In any event I think Linux users would be happy configuring the scheme handler by themselves if needed, with the possible assistance of a release note. It would certainly be unusual to try registering the handler every time the application starts. This would be something you would do once when you install, or when you notice it is missing, and leave it set up. But it's your application, and your users complaining if they see fit, so do whatever you think best. ___ 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: Relative paths in .desktop files
On 06/23/2011 06:47 AM, David Faure wrote: On Thursday 23 June 2011, Michael Thayer wrote: On Thu, 2011-06-23 at 11:58 +0200, David Faure wrote: On Monday 18 April 2011, Vincent Untz wrote: FWIW, I'd consider ./ to be relative to the path defined in the Path key (which could be ./ to tell that it's the base directory of the .desktop file). From a KDE point of view: I support these additions to the desktop entry spec and I volunteer to implement them in KDE. (In fact I just implemented support for Exec=./foo here, but that's useless by itself if it requires on a Path that has to be absolute, so the next step is to implement Path=. if we all agree on that syntax). Great. Would you like me to post an updated patch against the spec, as in e.g. [ http://lists.freedesktop.org/archives/xdg/2011-April/011887.html ], or Ah I seem to have missed some emails in this thread, thanks for the pointers. I am definitely NOT in favour of Type=ApplicationRelative, this would require many more adaptations to the code in many places, and it moves a rather special case to a very proeminent place -- should we have Type=ApplicationWithPath when Path is set, and Type=ApplicationWithTerminal when a terminal should show up? Sorry for the reasoning by the absurd or whatever that's called -- my point is that there's a combinatorial issue in putting too much information into Type. This discussion is about a small change in the file describing an application, let's keep Type=Application. does [ http://lists.freedesktop.org/archives/xdg/2011-April/011882.html ] look good to you? It says that ./ is relative to the location of the .desktop file. I can see the idea behind it, but then what happens when Path is set? From an implementation point of view it's easier to chdir(Path) and then execute ./foo, but I can see how from a user point of view the idea is maybe more to say resolve to a full path from the directory containing the .desktop file, then chdir(Path), then run the executable with a full path? I'm talking about a case like /home/dfaure/foo.desktop saying: Exec=./foo Path=/tmp Should this do (cd /tmp ; ./foo) or (cd /tmp ; /home/dfaure/foo) ? I'm guessing the latter is more useful, but maybe less expected. (More useful because the first one can be done with Exec=/tmp/foo, since in that case we know about /tmp as an absolute path anyway). I continue to oppose this. As I understand it, the intended use is for installation kits similar to how Autorun works on Windows. I would also refer everyone to the Autostart spec http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html which, in section Autostart of Applications After Mount, already deals with this after a fashion. I am not convinced that definition does not suffer from the same problems I point out here. The current way this proposal is defined is of no use for the existing applications of Desktop Entry, to wit the application menu (/usr/share/applications) and the X sessions menu (/usr/share/xsessions). The current proposal breaks the separation between architecture independent items like the icon and architecture dependent items like the executable. I would like someone to take me through how the multi-architecture scenario would work. If Exec points to a relative path, how do we have an install kit that has a binary for x86, a binary for s390, and a binary for arm, all of which are currently important Linux architectures. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: default apps
On 06/18/2011 11:33 AM, Matthew Monaco wrote: I'm finding inconsistent information about how to set system-wide default applications. Do I do it with mimeapps.list or defaults.list? In general is the default app part of the desktop spec or the mime spec? Is there a difference between doing it systemwide vs per-user (filenames, locations, etc)? I'm using GNOME 3, are there are special quirks here I should know about? Unlikely, but does anyway know of a way for firefox/thunderbird to honor the system settings for mime types? This in particular has been very frustrating for my parents, it seems like every day these settings change. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg This is somewhat unstable at this time. Any answer could be correct depending on the specific desktop environment you were running. I do not run GNOME so I am not familiar with the details of how they do it. There is a standard that would be draft proposed if this were a standards body. It uses mimeapps.list as its persistent store. In that document, the system-wide vs per-user is handled in the usual way with the XDG_DATA_DIRS search list. http://www.freedesktop.org/wiki/Specifications/mime-actions-spec As to Firefox, they have their own way of configuring this in the Firefox profile and settings dialog. You would have to raise it with any specific application you were interested in convincing to change their existing behavior. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: app id in desktop file
On 05/06/2011 06:31 PM, Ryan Lortie wrote: hi Sander, On Fri, 2011-05-06 at 16:58 -0500, Sander Jansen wrote: Why? For what purpose? There are quite a lot of reasons that I can imagine why this might be useful. For example, desktop environments could use it to match between the DBus name acquired by the application (which would be the same as the application ID) in order to match it with the desktop file. My immediate reason for this, though, is that it was suggested to me by Michael Vogt when I asked him if we could have metadata in apt mapping between application IDs and package names (ie: so you can query the package manager by app id). Having the key in the desktop file would be a good way to allow application authors to provide that information in a semi-normalised format for consumption by scripts. I think we have a lot of disjoint namespaces like wmclass, binary names, package names, D-Bus names, GSettings schema names, GApplication IDs and so on. A lot of these are already the same (ie: equal to the D-Bus name). It would really nice if we could get a strong story for mapping between these and the rest of them and this could provide that. Cheers ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg As I see it the application ID examples you've talked of are non user visible implementation artifacts. The closest thing to an application ID that the user is familiar with is the package name as seen in the package manager. It does not help transparency to have a non user visible implementation artifact take on more significance than it has now. Overriding and hiding in menus is done on the basis of desktop-file-id, the part of the .desktop name before the dot. If you were to start changing those on a whim, you would break all of the user-specific desktop files in people's .local/share/applications for no purpose. A bad idea, particularly when your starting point is only that it might be useful. If you wanted to put it in the .desktop files that GNOME ships as an X-GNOME-key, I would have no objection whatever to that. You are free to confuse your users as much as they will tolerate. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: ck-history
On 04/22/2011 01:59 PM, Scott Salley wrote: I've been investigating some bugs with gdm and the user list it displays and discovered that gdm relies on ck-history. Is there a spec or something for ck-history, because I have some questions about how it should behave? The specific problem I have is that user names are truncated at 8 characters, which seems a rather archaic limit. I'd like to discuss with someone the conditions on which this limit (and maybe others) could be removed. I have a patch for the 'ck-history --frequent' case which calculates the longest name length so column output is preserved, but that feels incomplete since it only handles the one case. Additionally, I noticed that ck-history will looks for older log files (i.e. /var/log/ConsoleKit/history.2.gz) which seems odd. If someone has rotated history.log out of the way, should it really be parsing through it? ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg The ConsoleKit site is http://www.freedesktop.org/wiki/Software/ConsoleKit with the mailing list at http://lists.freedesktop.org/mailman/listinfo/ConsoleKit I know there is some overlap with XDG, but that would give you best results for your inquiries. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
On 04/11/2011 10:08 AM, PCMan wrote: My fault! Field code %k is the file path of the desktop entry file, not it's parent directory. So if you named the shell script after the desktop file, like installer.desktop.sh, I think an Exec key like this should work. Exec=%k.sh This is a little bit tricky, but I think it can solve your problem. On Mon, Apr 11, 2011 at 9:08 PM, Michael Thayer michael.tha...@oracle.com wrote: On Sat, 2011-04-09 at 15:34 +0800, PCMan wrote: An easy workaround might be like this: [...] Exec=%k/installer.sh The field code %k will be expanded to the location of desktop entry file. This can solve your problem, in a more or less dirty way. I tried this out (Nautilus 2.32.0 in Ubuntu 10.10) and unless I did something wrong it failed to work. Among the past threads I found discussing this, this posting by Waldo Bastian in 2006 - http://lists.freedesktop.org/archives/xdg/2006-August/006885.html - sounds like he was happy with the idea of relative paths for icons: [quote] Prefix with ./ sounds good: * If it starts with / it's an absolute path * If it starts with ./ is's a relative path * Everything else is a themed icon name [end quote] How would other (particularly GNOME) people today see this (for executables too), and if favourably, where should I look for the code which Nautilus uses to process desktop files? I realise of course that what I have in mind isn't quite the way .desktop files are used, but it is sufficiently close that it seems to me silly to do something separate. Regards, Michael P.S. PCMan, I hope that you don't mind my CC-ing this back to the list. On Fri, Apr 8, 2011 at 6:28 PM, Michael Thayer michael.tha...@oracle.com wrote: [...] I immediately ran up against the problem that all paths in .desktop files have to be absolute, which obviously isn't an option here. So of course, the question is what the prospects are of getting this changed (I'm also open to suggestions about better ways). And since we are drifting towards the old AppFolder thing here anyway (which I know has been raised every so often here in the past, but never seems to have gone anywhere), what about some convention which would let one put a .desktop file in a directory and have it be a default executable for that directory? Just to be clear, since this is not the most important problem we have to solve I won't be able to spend a lot of time on it, but if someone can give me good enough pointers I might find a bit of time to write a couple of patches on my own time out of personal interest. -- ORACLE Deutschland B.V. Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg I still have not seen a crisp definition of what you are proposing that a relative path specification mean. The question relative to what has not been answered. If you were to propose some specific text change that could be commented on, in sufficient detail that its implementation is unambiguous, that would help a lot. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
On 04/11/2011 12:06 PM, Michael Thayer wrote: Hello Marty, On Mon, 2011-04-11 at 11:11 -0400, Marty Jack wrote: [...] On Fri, Apr 8, 2011 at 6:28 PM, Michael Thayer michael.tha...@oracle.com wrote: [...] I immediately ran up against the problem that all paths in .desktop files have to be absolute, which obviously isn't an option here. [...] I still have not seen a crisp definition of what you are proposing that a relative path specification mean. The question relative to what has not been answered. If you were to propose some specific text change that could be commented on, in sufficient detail that its implementation is unambiguous, that would help a lot. Thanks for the answer. Please find a patch against desktop-entry-spec-1.1.xml below. I hope that that, together with my initial posting, makes my intentions slightly clearer. As I said, I would also interested in other approaches to achieve the same thing. By the way, google has already answered my question about where in the GNOME source code desktop files are handled ([http://git.gnome.org/browse/glib/tree/gio/gdesktopappinfo.c]). I would probably not want to attempt anything for other DEs just now. Regards, Michael --- desktop-entry-spec-1.1.xml2011-04-11 17:50:02.350865289 +0200 +++ desktop-entry-spec-1.1.xml.new2011-04-11 17:57:39.126810018 +0200 @@ -429,7 +429,10 @@ entry Icon to display in file manager, menus, etc. If the name is an absolute path, the given file will be - used. If the name is not an absolute path, the algorithm described + used. If it starts with ./ it will be treated as a path + relative to the directory containing the desktop file and + the given file will be used. Otherwise, the algorithm + described in the ulink url=http://freedesktop.org/wiki/Standards/icon-theme-spec;Icon Theme Specification/ulink will be used to locate the icon. @@ -471,10 +474,12 @@ entry id=key-tryexecvarnameTryExec/varname/entry entry Path to an executable file on disk used to determine if the program - is actually installed. If the path is not an absolute path, the file - is looked up in the $PATH environment variable. If the file is not - present or if it is not executable, the entry may be ignored (not be - used in menus, for example). + is actually installed. If the path is not an absolute path and does + not start with ./, the file is looked up in the $PATH + environment variable. Paths starting with ./ are treated as being + relative to the directory containing the desktop file. If the file + is not present or if it is not executable, the entry may be + ignored (not be used in menus, for example). /entry entrystring/entry entryNO/entry @@ -572,7 +577,9 @@ The varnameExec/varname key must contain a command line. A command line consists of an executable program optionally followed by one or more arguments. - The executable program can either be specified with its full path or + The executable program can either be specified with its full path, + with a path starting with ./ which is treated as relative to the + directory containing the desktop file, or with the name of the executable only. If no full path is provided the executable is looked up in the $PATH environment variable used by the desktop environment. Now we have something to discuss. Your proposed change is crisp and unambiguous. My first observation is that this new definition is in no way useful for existing .desktop files as used in application menu processing or in the available sessions menu (/usr/share/xsessions). We should never expect to have executables in a /share directory because they are architecture specific and the desktop file is architecture independent. By convention icons are either somewhere under /share/icons or in /share/pixmaps and located via the Icon Theme specification. This is done this way so that themes can supersede the application supplied icon. That being said, I am not certain this belongs in the Desktop Entry specification. If this were added I think we need a statement in the Menu specification that this construction is not allowed in those .desktop files. Your intended usage sounds more along the lines of an Autorun file. Maybe you should call it autorun.inf and put whatever you like in it. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
On 04/11/2011 12:06 PM, Michael Thayer wrote: Hello Marty, On Mon, 2011-04-11 at 11:11 -0400, Marty Jack wrote: [...] On Fri, Apr 8, 2011 at 6:28 PM, Michael Thayer michael.tha...@oracle.com wrote: [...] I immediately ran up against the problem that all paths in .desktop files have to be absolute, which obviously isn't an option here. [...] I still have not seen a crisp definition of what you are proposing that a relative path specification mean. The question relative to what has not been answered. If you were to propose some specific text change that could be commented on, in sufficient detail that its implementation is unambiguous, that would help a lot. Thanks for the answer. Please find a patch against desktop-entry-spec-1.1.xml below. I hope that that, together with my initial posting, makes my intentions slightly clearer. As I said, I would also interested in other approaches to achieve the same thing. By the way, google has already answered my question about where in the GNOME source code desktop files are handled ([http://git.gnome.org/browse/glib/tree/gio/gdesktopappinfo.c]). I would probably not want to attempt anything for other DEs just now. Regards, Michael --- desktop-entry-spec-1.1.xml2011-04-11 17:50:02.350865289 +0200 +++ desktop-entry-spec-1.1.xml.new2011-04-11 17:57:39.126810018 +0200 @@ -429,7 +429,10 @@ entry Icon to display in file manager, menus, etc. If the name is an absolute path, the given file will be - used. If the name is not an absolute path, the algorithm described + used. If it starts with ./ it will be treated as a path + relative to the directory containing the desktop file and + the given file will be used. Otherwise, the algorithm + described in the ulink url=http://freedesktop.org/wiki/Standards/icon-theme-spec;Icon Theme Specification/ulink will be used to locate the icon. @@ -471,10 +474,12 @@ entry id=key-tryexecvarnameTryExec/varname/entry entry Path to an executable file on disk used to determine if the program - is actually installed. If the path is not an absolute path, the file - is looked up in the $PATH environment variable. If the file is not - present or if it is not executable, the entry may be ignored (not be - used in menus, for example). + is actually installed. If the path is not an absolute path and does + not start with ./, the file is looked up in the $PATH + environment variable. Paths starting with ./ are treated as being + relative to the directory containing the desktop file. If the file + is not present or if it is not executable, the entry may be + ignored (not be used in menus, for example). /entry entrystring/entry entryNO/entry @@ -572,7 +577,9 @@ The varnameExec/varname key must contain a command line. A command line consists of an executable program optionally followed by one or more arguments. - The executable program can either be specified with its full path or + The executable program can either be specified with its full path, + with a path starting with ./ which is treated as relative to the + directory containing the desktop file, or with the name of the executable only. If no full path is provided the executable is looked up in the $PATH environment variable used by the desktop environment. Having thought about this just a moment more, I note that I forgot to mention the other main existing usage, Autostart, where the same considerations would apply. I wonder if there isn't an argument for a new Type= in order to differentiate this case where you have everything lumped into the one directory. It feels quite distinct. There's nothing GNOME specific about this, and it should work on any DE. The code you referenced is in glib, which just happens to be hosted on the GNOME site for historical reasons. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Relative paths in .desktop files
On 04/11/2011 05:35 PM, Michael Thayer wrote: On Mon, 2011-04-11 at 22:42 +0200, Michael Thayer wrote: Using a new Type as you suggested (Type=ApplicationRelative? Or is that too ugly?) might indeed be more sensible (and aesthetical) than the ./ prefix. Someone might even want to keep such a desktop file under something/share/applications and have paths starting with ../.. ... Should I send a new patch on that basis? Regards, Michael Personally, I would wait to see if there is more feedback from others before changing anything. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Current source for basedir-spec?
On 04/11/2011 08:51 PM, Richard Hartmann wrote: Hi all, where can I find the current source to basedir-spec? The webcvs [1] only goes to 0.6 while cgit.f.o [2] does not list basedir-spec at all. If I were to submit a patch to list the default values in a table or a similar form that is easier quicker to read than the current one, would it be accepted as 0.7.1 or 0.8? Thanks, Richard [1] http://webcvs.freedesktop.org/basedir/basedir-spec/basedir-spec.xml?view=markup [2] http://cgit.freedesktop.org/ ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg http://cgit.freedesktop.org/xdg/xdg-specs/tree/ ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Spec for running binary tarball?
On 03/22/2011 07:24 PM, Daniel Bo wrote: Is there a spec for a DE to run a binary tarball, for instance if the archive's executable bit is set, the archive is extracted to /tmp and a specially named script is executed? If so, how could FD.o get distributer's that distribute a single, distro-agnostic package (like Mozilla et al.) on board? You might want to check out the Zero-Install project. http://0install.net/ ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Adding Unity to OnlyShowIn allowed values
On 02/24/2011 06:10 AM, Pierre Wieser wrote:
Sorry I am late to the party here and may be off thread. This was
discussed back in 2009 with the proposal at that time being
XDG_CURRENT_DESKTOP.
The shipping versions of LXDE have been using this to control how the
menu processor matches OnlyShowIn and NotShowIn. It also uses
XDG_MENU_PREFIX to control the file lookup on the toplevel
${XDG_MENU_PREFIX}applications.xml
http://lists.freedesktop.org/archives/xdg/2009-August/010940.html
I was not conscious of that thread, and, yes, XDG_CURRENT_DESKTOP is
prefectly fine for me.
But I never have seen this variable in any spec ? Should'n it be written
somewhere ?
Regards
Pierre
I think what happened is that proposal never made it into an actual spec
update. If there is consensus now, I will do a patch. I have a few other
clarification/textual patches to Basedir, DE, and Menu that I could propose now
also that came out of a fresh look at implementing a menu processor.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Adding Unity to OnlyShowIn allowed values
That being said, I think it might be worth a standard environment
variable to get that. There isn't one that I know of today.
I agree.
May I propose XDG_DESKTOP ?
Regards
Pierre
Sorry I am late to the party here and may be off thread. This was discussed
back in 2009 with the proposal at that time being XDG_CURRENT_DESKTOP.
The shipping versions of LXDE have been using this to control how the menu
processor matches OnlyShowIn and NotShowIn. It also uses XDG_MENU_PREFIX to
control the file lookup on the toplevel ${XDG_MENU_PREFIX}applications.xml
http://lists.freedesktop.org/archives/xdg/2009-August/010940.html
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg
