desktop files
I hope this is the right list... My question is essentially where should desktop files be installed? http://developer.gnome.org/integration-guide/stable/desktop-files.html.en suggests /usr/share/applications or ~.local/share/applications however if you want your at-spi daemon to start, etc/xdg/autostart/at-spi-dbus-bus.desktop might be a good place. Which is right? Was one historically right, and things have changed? Any hints appreciated! Cheers, Patrick ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop files
Le vendredi 25 novembre 2011 à 12:54 +, Patrick Welche a écrit : I hope this is the right list... My question is essentially where should desktop files be installed? http://developer.gnome.org/integration-guide/stable/desktop-files.html.en suggests /usr/share/applications or ~.local/share/applications Actually, you should use /usr/share/applications if you're installing your app to /usr, /usr/local/share/applications if you're installing it to /usr/local, and ~/.local/share/applications if you're installing it to ~. These come from the default values recommended in the Base Directory Specification[1], and defined in the Desktop Menu Specification [2][3]. This applies to applications that should be made visible to the user. however if you want your at-spi daemon to start, etc/xdg/autostart/at-spi-dbus-bus.desktop might be a good place. These OTC should be used when you want your program to start on login. The same rules as above apply: use /etc/xdg/autostart/ for installs to /usr, and ~/.config/autostart for installs to ~. This is defined in the Desktop Application Autostart Specification [4]. Hope this helps. 1: http://standards.freedesktop.org/basedir-spec/latest/ 2: http://standards.freedesktop.org/menu-spec/latest/apc.html 3: http://standards.freedesktop.org/menu-spec/latest/apcs02.html 4: http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How to control desktop files
Le jeudi 08 juillet 2010 à 16:09 -0500, Brian Cameron a écrit : One crude way to resolve this problem would be to simply not install (or uninstall) packages that introduce desktop files. However, this is not an ideal solution for many reasons. It is especially a problem for Oracle because Oracle's terminal server product, Sun Ray, runs on many Linux distros (Fedora, Debian, Ubuntu, openSuse, Gentoo), so it would be ideal if there were a solution that just worked nicely across distros. A sysadmin should be able to specify what desktop files to ignore without requiring distro specific setup (such as uninstalling packages or hand-editing desktop files). It would be best if any needed changes could just be installed with the Sun Ray product and things would just work. In Debian we have a hack for gnome-menus that adds a blacklist of applications you don’t want to see in the menus. It was easier to do that than patching all the KDE desktop files to add OnlyShowIn/NotShowIn options. Currently it’s very distribution-specific as it regenerates desktop files on the fly, but maybe this behavior could be implemented in gnome-menus if deemed useful. A similar patch would be needed for gnome-session to disable some of the startup files. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
How to control desktop files
Many OpenSolaris users use GNOME in a terminal server environment, and we notice some serious usability problems with running GNOME in this way. I was wondering if someone might be able to suggest some recommended ways to address these problems. Many of the problems relate to Desktop files. In a terminal server environment you often do not want users to be able to run programs that require elevated privileges, so System Tools (e.g. package managers, etc.) should not show up in the menus. Developer tools may not make sense to display in some environments. Also, users in a terminal server environment may not have access to certain devices which may make some programs not useful (e.g. a power management or battery status tool). Similarly, some programs that are autostarted may not make sense in a terminal server environment, such as power management/package manager related user daemons. Since the GNOME autostart mechanism also uses Desktop files, this seems a related problem. One crude way to resolve this problem would be to simply not install (or uninstall) packages that introduce desktop files. However, this is not an ideal solution for many reasons. It is especially a problem for Oracle because Oracle's terminal server product, Sun Ray, runs on many Linux distros (Fedora, Debian, Ubuntu, openSuse, Gentoo), so it would be ideal if there were a solution that just worked nicely across distros. A sysadmin should be able to specify what desktop files to ignore without requiring distro specific setup (such as uninstalling packages or hand-editing desktop files). It would be best if any needed changes could just be installed with the Sun Ray product and things would just work. I know that the Desktop Specification supports TryExec which does offer some control over whether desktop files should be ignored. However, it does not seem that this is powerful enough to provide the flexibility needed. Desktop files also support a Category field. Is it possible to tell GNOME to ignore desktop files that have a particular values like System and Settings. For example, on user session startup, GDM (and most display managers) sources any files in the /etc/X11/xinit/xinitrc.d directory, so perhaps this could be solved by setting up an environment variable before session startup with a list of categories or desktop file names to ignore. This would work well since it would allow the sysadmin to control what desktop files to ignore via the /etc/X11/xinit/xinitrc.d interface and without needing to modify any GNOME packages or files. Another possible solution might be to store the list of categories or desktop files to ignore in a GConf setting that gnome-session or GNOME Shell checks, and which the sysadmin could setup as mandatory system-wide settings. This seems a generally useful feature in a variety of contexts, not just terminal servers. Many projects may want to provide software on a variety of platforms and have the ability to control on which platforms desktop files should be used or not. Or is there already a way to implement this sort of feature that I do not know about? If not, would it be acceptable to enhance gnome-session and GNOME Shell to support this sort of feature, perhaps with the sort of solution suggested above? Since this feature is of particular interest to Oracle, resources can be provided to do any work needed to make this functionality work well assuming we can come up with an acceptable design. A similar problem is with panel applets. Some applets do not make sense to display and run in a terminal server environment, such as the battery status applet. What is the proper behavior for applets in this situation? For example, should an applet be written to be smart enough to recognize that it is not needed and exit itself? If so, is there an example of a GNOME applet which does this sort of thing? Or is there some interface to control what applets should not be run in certain environments? Or would interfaces need to be added to support this ability? Thanks, Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
FWD: App maintainers: Please double check StartupNotify=true in your desktop files
Hi, Basically, please double check that your app has StartupNotify=true in your .desktop file. If it doesn't, it's almost certainly a bug. See original posting here: http://lists.fedoraproject.org/pipermail/devel/2010-March/133523.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Window managers and their desktop files
Matthias Clasen wrote: On Mon, Sep 15, 2008 at 1:27 PM, Dan Winship [EMAIL PROTECTED] wrote: The basic format of the desktop entry file requires that there be a group header named Desktop Entry. There may be other groups present in the file... There should be nothing preceding [the Desktop Entry] group in the desktop entry file but possibly one or more comments. If there are apps that fail when a Window Manager group is present after the Desktop Entry group, then those apps are broken. desktop-file-validate considers it broken... Hm... metacity.desktop: error: file contains group Window Manager, but groups extending the format should start with X- Oh, it's not complaining that there's an additional group, it just doesn't like the name. And sure enough, the spec does say that non-standard groups should use [X-PRODUCT GROUPNAME], it's just in a different part of the spec from where I was looking. My bad. (But that means [X-Window Manager] would still be wrong though; it should be [X-GNOME Window Manager].) -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Absolute paths to applications in .desktop files
Le mercredi 23 juillet 2008, à 01:59 +0100, Alexander Jones a écrit : Hi 2008/7/23 Vincent Untz [EMAIL PROTECTED]: This is more complex than that. If I copy a launcher from the applications menu to my panel or desktop and then run my session in jhbuild, I might want to use the jhbuilt application instead of the system application. If the user changes $PATH, then it has to be expected that some things might break. Also, if the user has gcalctool in $HOME/bin, he'll run into weird things when typing gcalctool in the run dialog, eg. This highlights an issue I've been meaning to bring up... The way we deal with creating panel/desktop launchers is by COPYING the Desktop Entry file. Desktop Entry files should, IMO, only be used to define applications. Launchers, etc., should be pointing to them instead. Actually, the panel does not copy them and directly use the file. That's fine, until the user starts modifying it, in which case we have no choice and we have to fork the file. Nautilus doesn't do that, though. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Absolute paths to applications in .desktop files
Le mercredi 23 juillet 2008 à 01:47 +0200, Vincent Untz a écrit : This is more complex than that. If I copy a launcher from the applications menu to my panel or desktop and then run my session in jhbuild, I might want to use the jhbuilt application instead of the system application. Interesting; I thought it would be more interesting for jhbuild if icons would specify the absolute path, allowing to install both versions at the same time. But if that is actually your workflow it might be more useful to only specify the full path in distro-shipped .desktop files. If the user changes $PATH, then it has to be expected that some things might break. Sure, and this is the reason why this issue is not so important, but it is still better to allow him to do so without breaking things. Also, if the user has gcalctool in $HOME/bin, he'll run into weird things when typing gcalctool in the run dialog, eg. Indeed, but in this case he presumably wants it so. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Absolute paths to applications in .desktop files
2008/7/23 Vincent Untz [EMAIL PROTECTED]: Actually, the panel does not copy them and directly use the file. That's fine, until the user starts modifying it, in which case we have no choice and we have to fork the file. Nautilus doesn't do that, though. I didn't realise that. I can see though, that when I edit the menu and simply make an item visible, it forks the Desktop Entry and just changes the hidden field in ~/.local/share/applications ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Absolute paths to applications in .desktop files
Hi, Le mercredi 09 juillet 2008, à 23:28 +0200, Josselin Mouette a écrit : Hi, the topic was raised on debian-devel and I think we should make sure that we are not missing anything before someone starts a crusade about it, so I prefer asking here. Currently, none of the .desktop files shipped in GNOME modules specify an absolute path for the executable. However this is desirable for the following reasons (shamelessly quoting Vincent Lefevre, as I don’t have much to add): 1. Each .desktop file is a file associated with /usr/bin/something, which is distributed in the same package. 2. Taking the user's $PATH into account may have unexpected effects, such as running a different version of the program which may accept a different set of MIME types, or worse, running another program installed it the user’s $HOME/bin directory. 3. In config files, $PATH is generally used when one doesn't know the location of the program, for flexibility, but this is not the case here (see point 1). Currently, in Debian, we hardcode the path specifically for gnome-games – as executables are in /usr/games and some stupid users remove it from their PATH – but not for the rest, and given the reasons above, I don’t understand why they are not directly hardcoded upstream. Am I missing something or is it just about not having too many .desktop.in.in files? This is more complex than that. If I copy a launcher from the applications menu to my panel or desktop and then run my session in jhbuild, I might want to use the jhbuilt application instead of the system application. If the user changes $PATH, then it has to be expected that some things might break. Also, if the user has gcalctool in $HOME/bin, he'll run into weird things when typing gcalctool in the run dialog, eg. So I'm not sure this is worth it. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Absolute paths to applications in .desktop files
Hi 2008/7/23 Vincent Untz [EMAIL PROTECTED]: This is more complex than that. If I copy a launcher from the applications menu to my panel or desktop and then run my session in jhbuild, I might want to use the jhbuilt application instead of the system application. If the user changes $PATH, then it has to be expected that some things might break. Also, if the user has gcalctool in $HOME/bin, he'll run into weird things when typing gcalctool in the run dialog, eg. This highlights an issue I've been meaning to bring up... The way we deal with creating panel/desktop launchers is by COPYING the Desktop Entry file. Desktop Entry files should, IMO, only be used to define applications. Launchers, etc., should be pointing to them instead. Another example where this breaks is if you uninstall an application, or if its binary name changes, or icon name, or translation of name or description... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Absolute paths to applications in .desktop files
Hi, the topic was raised on debian-devel and I think we should make sure that we are not missing anything before someone starts a crusade about it, so I prefer asking here. Currently, none of the .desktop files shipped in GNOME modules specify an absolute path for the executable. However this is desirable for the following reasons (shamelessly quoting Vincent Lefevre, as I don’t have much to add): 1. Each .desktop file is a file associated with /usr/bin/something, which is distributed in the same package. 2. Taking the user's $PATH into account may have unexpected effects, such as running a different version of the program which may accept a different set of MIME types, or worse, running another program installed it the user’s $HOME/bin directory. 3. In config files, $PATH is generally used when one doesn't know the location of the program, for flexibility, but this is not the case here (see point 1). Currently, in Debian, we hardcode the path specifically for gnome-games – as executables are in /usr/games and some stupid users remove it from their PATH – but not for the rest, and given the reasons above, I don’t understand why they are not directly hardcoded upstream. Am I missing something or is it just about not having too many .desktop.in.in files? Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: .desktop files shipping the obsolete Application category
Claudio Saavedra wrote: Before I start filing bug reports I would like to know, if you (GNOME) still use the Application category, that I can find in almost all .desktop files you ship. The category AFAIK is some old relict of GNOME = 2.4 and not a valid nor registered category following the current freedesktop.org specification, which is AFAIK supported since 2.4 - 2.8. Now GNOME reached 2.18 and I can still find this category. So is it still used somewhere? If yes, is it necessary? If no: How do you handle muss bug-filing normally? There was a GNOME Goal about removing the Application category shortly before 2.18 was released. Most probably, not all the applications in the release set fixed this right in time. For SuSE it is: https://bugzilla.novell.com/show_bug.cgi?id=254654 I already removed Application from all SuSE patches and spec files (i. e. places where SuSE explicitly added it). I plan to reopen it after a year or so and patch remaining applications, where upstream did not fix it. It would be enough to make this error fatal in desktop-file-validate. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: .desktop files shipping the obsolete Application category
Le jeudi 21 juin 2007, à 11:14 +0200, Stanislav Brabec a écrit : I already removed Application from all SuSE patches and spec files (i. e. places where SuSE explicitly added it). I plan to reopen it after a year or so and patch remaining applications, where upstream did not fix it. It would be enough to make this error fatal in desktop-file-validate. It can easily be done, but I didn't want to do too soon, since really a lot of modules were broken. Another option is probably to add a --no-deprecate argument to desktop-file-validate, which changes deprecation warnings into errors. Do you want to open a bug in fdo bugzilla? :-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: .desktop files shipping the obsolete Application category
Vincent Untz wrote: Le jeudi 21 juin 2007, à 11:14 +0200, Stanislav Brabec a écrit : I already removed Application from all SuSE patches and spec files (i. e. places where SuSE explicitly added it). I plan to reopen it after a year or so and patch remaining applications, where upstream did not fix it. It would be enough to make this error fatal in desktop-file-validate. It can easily be done, but I didn't want to do too soon, since really a lot of modules were broken. Another option is probably to add a --no-deprecate argument to desktop-file-validate, which changes deprecation warnings into errors. Do you want to open a bug in fdo bugzilla? :-) Let's wait some time for upstream fixes. Otherwise it will break a lot of packages. In time of last check, about 40% of all desktop files have had Application in Categories. After a year or so we can fix the rest. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12tel: +420 284 028 966 190 00 Praha 9fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
.desktop files shipping the obsolete Application category
Hi, Before I start filing bug reports I would like to know, if you (GNOME) still use the Application category, that I can find in almost all .desktop files you ship. The category AFAIK is some old relict of GNOME = 2.4 and not a valid nor registered category following the current freedesktop.org specification, which is AFAIK supported since 2.4 - 2.8. Now GNOME reached 2.18 and I can still find this category. So is it still used somewhere? If yes, is it necessary? If no: How do you handle muss bug-filing normally? PS: I don't need CCs. I'm subscribed to the list. Regards, Daniel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: .desktop files shipping the obsolete Application category
Hi Daniel, On Wed, 2007-05-30 at 02:55 +0200, Daniel Leidert wrote: Hi, Before I start filing bug reports I would like to know, if you (GNOME) still use the Application category, that I can find in almost all .desktop files you ship. The category AFAIK is some old relict of GNOME = 2.4 and not a valid nor registered category following the current freedesktop.org specification, which is AFAIK supported since 2.4 - 2.8. Now GNOME reached 2.18 and I can still find this category. So is it still used somewhere? If yes, is it necessary? If no: How do you handle muss bug-filing normally? There was a GNOME Goal about removing the Application category shortly before 2.18 was released. Most probably, not all the applications in the release set fixed this right in time. The progress of this goal can be found here: http://live.gnome.org/GnomeGoals/ApplicationCategory Claudio -- Claudio Saavedra [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Application category in desktop files
Hi, I recently discovered that Application isn't a valid category in the desktop specification, despite being used in most desktop files: [EMAIL PROTECTED] /usr/share/applications $ grep Categories *.desktop | grep Application | wc -l 84 Should there be a GnomeLove mission to clean up the categories field in every desktop file? Removing Application, adding GNOME, adding OnlyShowIn as relevant, making sure as many categories are possible are specified, and so on. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application category in desktop files
Hi, This is a very nice and simple idea for Gnome Goals. Also, nice as a GNOME Love activity. It's a pity the idea came after code freeze. Cheers! --lucasr 2007/3/6, Ross Burton [EMAIL PROTECTED]: Hi, I recently discovered that Application isn't a valid category in the desktop specification, despite being used in most desktop files: [EMAIL PROTECTED] /usr/share/applications $ grep Categories *.desktop | grep Application | wc -l 84 Should there be a GnomeLove mission to clean up the categories field in every desktop file? Removing Application, adding GNOME, adding OnlyShowIn as relevant, making sure as many categories are possible are specified, and so on. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application category in desktop files
Le mardi 06 mars 2007 à 11:13 +0200, Lucas Rocha a écrit : Hi, This is a very nice and simple idea for Gnome Goals. Also, nice as a GNOME Love activity. It's a pity the idea came after code freeze. .desktop aren't really code. release team hat I think we can accept those changes without going through hard code freeze request. /release team hat Are other release team members opposed to that ? -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application category in desktop files
2007-03-06 klockan 10:13 skrev Lucas Rocha: 2007/3/6, Ross Burton [EMAIL PROTECTED]: Should there be a GnomeLove mission to clean up the categories field in every desktop file? Removing Application, adding GNOME, adding OnlyShowIn as relevant, making sure as many categories are possible are specified, and so on. This is a very nice and simple idea for Gnome Goals. Also, nice as a GNOME Love activity. It's a pity the idea came after code freeze. Here you go, Lucas ;) Index: eog.desktop.in.in === --- eog.desktop.in.in (revision 3617) +++ eog.desktop.in.in (working copy) @@ -8,7 +8,7 @@ Icon=eog StartupNotify=true Terminal=false Type=Application -Categories=GNOME;GTK;Application;Graphics;RasterGraphics;Viewer; +Categories=GNOME;GTK;Graphics;RasterGraphics;Viewer; X-GNOME-Bugzilla-Bugzilla=GNOME X-GNOME-Bugzilla-Product=EOG X-GNOME-Bugzilla-Component=general mvrgr, Wouter -- :wq mail [EMAIL PROTECTED] web http://uwstopia.nl sugar sugar :: you couldn't come come :: sugar sugar -- heather nova signature.asc Description: Digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application category in desktop files
Hei, 2007/3/6, Frederic Crozat [EMAIL PROTECTED]: Le mardi 06 mars 2007 à 11:13 +0200, Lucas Rocha a écrit : Hi, This is a very nice and simple idea for Gnome Goals. Also, nice as a GNOME Love activity. It's a pity the idea came after code freeze. .desktop aren't really code. I know. I was just being pedantic community member and considering we cannot change anything anymore. :-) release team hat I think we can accept those changes without going through hard code freeze request. /release team hat Create a wiki page for this goal? --lucasr Are other release team members opposed to that ? -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application category in desktop files
On Tue, 2007-03-06 at 08:58 +, Ross Burton wrote: Hi, I recently discovered that Application isn't a valid category in the desktop specification, despite being used in most desktop files: [EMAIL PROTECTED] /usr/share/applications $ grep Categories *.desktop | grep Application | wc -l 84 Should there be a GnomeLove mission to clean up the categories field in every desktop file? Removing Application, adding GNOME, adding OnlyShowIn as relevant, making sure as many categories are possible are specified, and so on. Very good idea. I recently removed it from Totem after desktop-file-install complained about it. -- Bastien Nocera [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application category in desktop files
Le mardi 06 mars 2007, à 10:33, Frederic Crozat a écrit : Le mardi 06 mars 2007 à 11:13 +0200, Lucas Rocha a écrit : Hi, This is a very nice and simple idea for Gnome Goals. Also, nice as a GNOME Love activity. It's a pity the idea came after code freeze. .desktop aren't really code. release team hat I think we can accept those changes without going through hard code freeze request. /release team hat Are other release team members opposed to that ? I don't see how we could be opposed to this. If someone wants to create a GNOME Goal page for this, please go ahead! Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application category in desktop files
On Tue, 2007-03-06 at 14:23 +0100, Vincent Untz wrote: Le mardi 06 mars 2007, à 10:33, Frederic Crozat a écrit : Le mardi 06 mars 2007 à 11:13 +0200, Lucas Rocha a écrit : Hi, This is a very nice and simple idea for Gnome Goals. Also, nice as a GNOME Love activity. It's a pity the idea came after code freeze. .desktop aren't really code. release team hat I think we can accept those changes without going through hard code freeze request. /release team hat Are other release team members opposed to that ? I don't see how we could be opposed to this. If someone wants to create a GNOME Goal page for this, please go ahead! I'm creating the page in the wiki. Will send it later for you guys to review the wording and make sure the instructions are ok, before publishing it. Claudio -- Claudio Saavedra [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application category in desktop files
More generally you could validate all the files with desktop-file-install (assuming its validation rules are still up-to-date) Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application category in desktop files
Le mardi 06 mars 2007 à 10:05 -0500, Havoc Pennington a écrit : More generally you could validate all the files with desktop-file-install (assuming its validation rules are still up-to-date) Well, Applications category is a little special in desktop-file-install because it is outputting only a warning (not an error) because there are .desktop in the wild (read ISV) with Applications category. But it should output something on the terminal anyway. -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application category in desktop files
On Tue, 2007-03-06 at 11:04 -0300, Claudio Saavedra wrote: I'm creating the page in the wiki. Will send it later for you guys to review the wording and make sure the instructions are ok, before publishing it. Ok, I've added then a draft for this Goal here: http://live.gnome.org/GnomeGoals/ApplicationCategory I've set a note to specify this goal's instructions need to be reviewed before everyone goes and follows them. I added the goal as well in http://live.gnome.org/GnomeGoals/ Please review it and make sure everything is fine. I hope I haven't made any omission. In particular, I didn't add the bindings modules because I suppose they don't install desktop files, in case I'm wrong please feel free to correct it. Greetings, Claudio -- Claudio Saavedra [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application category in desktop files
Le mardi 06 mars 2007 à 13:52 -0300, Claudio Saavedra a écrit : On Tue, 2007-03-06 at 11:04 -0300, Claudio Saavedra wrote: I'm creating the page in the wiki. Will send it later for you guys to review the wording and make sure the instructions are ok, before publishing it. Ok, I've added then a draft for this Goal here: http://live.gnome.org/GnomeGoals/ApplicationCategory I've set a note to specify this goal's instructions need to be reviewed before everyone goes and follows them. I added the goal as well in http://live.gnome.org/GnomeGoals/ Please review it and make sure everything is fine. I hope I haven't made any omission. In particular, I didn't add the bindings modules because I suppose they don't install desktop files, in case I'm wrong please feel free to correct it. This is great. Could you add, as suggest by Havoc, a call to desktop-file-validate so people check they are generating valid .desktop file ? Thanks. -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application category in desktop files
On Tue, 2007-03-06 at 18:42 +0100, Frederic Crozat wrote: Could you add, as suggest by Havoc, a call to desktop-file-validate so people check they are generating valid .desktop file ? Done. Claudio -- Claudio Saavedra [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application category in desktop files
Le mardi 06 mars 2007, à 15:20, Claudio Saavedra a écrit : On Tue, 2007-03-06 at 18:42 +0100, Frederic Crozat wrote: Could you add, as suggest by Havoc, a call to desktop-file-validate so people check they are generating valid .desktop file ? Done. I've updated it it so that we also add the GTK category, we verify the other categories used in the .desktop file and we verify whether OnlyShowIn should be used or not. Looks great for me. If there's no other comment in the next day, feel free to announce the goal more widely! Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application category in desktop files
On Tue, 2007-03-06 at 20:38 +0100, Vincent Untz wrote: I've updated it it so that we also add the GTK category, we verify the other categories used in the .desktop file and we verify whether OnlyShowIn should be used or not. Great, thank you! Looks great for me. If there's no other comment in the next day, feel free to announce the goal more widely! Could you please announce it tomorrow in p.g.o? It'd be more effective than if I do it.. *cough*, *cough* Claudio -- Claudio Saavedra [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application category in desktop files
--- Ross Burton [EMAIL PROTECTED] wrote: Hi, I recently discovered that Application isn't a valid category in the desktop specification, despite being used in most desktop files: [...] this should resolve: http://bugzilla.gnome.org/show_bug.cgi?id=129268 (closed as invalid) http://bugzilla.gnome.org/show_bug.cgi?id=331142 (reopened 129268) better late... -- Fryderyk Dziarmagowski ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-open behavior reguarding .desktop files
Any further thoughts on this? I'm thinking we consider updating gnome-open for 2.18... Cheers, Kevin Kubasik On Tue, 2006-10-24 at 16:47 -0600, Tom Tromey wrote: Kevin == Kevin Kubasik [EMAIL PROTECTED] writes: Kevin Personally, I think that we should offer an API to execute .desktop file Kevin commands somewhere in the libgnome api, but maybe gnome-open isn't the Kevin place to do it? Please, all thoughts and commends welcome. There is an API for this in the gnome-desktop module. For the gnome-open program, it does sound reasonable that it would launch the .desktop file rather than open it with an editor. Tom signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
patch for gnome-menus bug (doesn't send notification for new .desktop files)
Please find attached a patch for the bug as described in [1].Note, I'm not on this list, so please CC me in replies.Thanks,Pete[1]
https://launchpad.net/distros/ubuntu/+source/gnome-menus/+bug/64264
diff -rc gnome-menus-2.16.1/libmenu/entry-directories.c gnome-menus-2.16.1.pdr/libmenu/entry-directories.c
*** gnome-menus-2.16.1/libmenu/entry-directories.c 2005-08-22 09:19:34.0 +0100
--- gnome-menus-2.16.1.pdr/libmenu/entry-directories.c 2006-10-20 06:00:00.0 +0100
***
*** 462,468
g_free (basename);
g_free (dirname);
! if (handled)
{
cached_dir_invoke_monitors (dir);
}
--- 462,468
g_free (basename);
g_free (dirname);
! if (!handled)
{
cached_dir_invoke_monitors (dir);
}
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-open behavior reguarding .desktop files
As per the comment on bug 343896 I am forwarding this to this list for discussion. To summarize the bug, libgnome's gnome-open will open a .desktop file with a text editor, causing several applications (such as deskbar-applet) to open .desktop files, when it is more likely that the user was expecting the command associated with the .desktop file to be run. Since this is a somewhat major behavior change to a standing api, what are peoples thoughts on such a change, would it be desired, or more of a pain then its worth? Personally, I think that we should offer an API to execute .desktop file commands somewhere in the libgnome api, but maybe gnome-open isn't the place to do it? Please, all thoughts and commends welcome. Cheers, Kevin Kubasik Bug: http://bugzilla.gnome.org/show_bug.cgi?id=343896 signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-open behavior reguarding .desktop files
Kevin == Kevin Kubasik [EMAIL PROTECTED] writes: Kevin Personally, I think that we should offer an API to execute .desktop file Kevin commands somewhere in the libgnome api, but maybe gnome-open isn't the Kevin place to do it? Please, all thoughts and commends welcome. There is an API for this in the gnome-desktop module. For the gnome-open program, it does sound reasonable that it would launch the .desktop file rather than open it with an editor. Tom ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome .desktop files
Em Sex, 2006-01-20 às 16:58 +0800, Davyd Madeley escreveu: It's my opinion that viewing apps should still appear in the Applications menu. [ snip all the reasons I had been wanting to write down for some time ] Yeah, I second that =) -- Guilherme de S. Pastore (fatalerror) [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome .desktop files
Quoting Stanislav Brabec [EMAIL PROTECTED]: This happens with a lot of applications, is this a bug or a feature? If I understand correctly, that would be a feature Yes. This bug is a feature. For example if you want to open application and then use DnD, or if you want to open web link using DnD, you will end by searching a file of the same type on the disc to be able to open the application. It's my opinion that viewing apps should still appear in the Applications menu. I may want to open my application and then open a file from the Recent Files list in that application, or select some specific function (eg. Play Disc). Perhaps I have been asked by a member of the support staff what version of Evince I am running, or as previously pointed out, I want to drag and drop an element (that is not a file in Nautilus) into the window to somehow open it (eg. this is the coolest way to open things in the screenshot app without having to save them outside a tempfile). Additionally, I feel it is by far the best metric to determine if you have a particular application installed without the user having to know squat about the package management system. --d ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gnome .desktop files
Hi, we are packaging gnome 2.12 for a Portuguese Linux distribution (www.alinex.org) and some of the application are not shown on the menu. For evince the file evince.desktop exits but has NoDisplay=true why? If we change it do false it works! This happens with a lot of applications, is this a bug or a feature? Best regards, Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome .desktop files
Hi ! This happens with a lot of applications, is this a bug or a feature? If I understand correctly, that would be a feature : do we really want all kinds of viewing applications clutter the menu ? I guess uers will just want evince (for example) to open when they double-click on a PDF or PS document, they probably won't open evince from the menu, then File-Open to find their document. I'm definitely not the one who decided this, but I guess this is the rationale (with which I fully agree) ? Cheers, Manu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome .desktop files
Manu Cornet wrote: Hi ! This happens with a lot of applications, is this a bug or a feature? If I understand correctly, that would be a feature Yes. This bug is a feature. For example if you want to open application and then use DnD, or if you want to open web link using DnD, you will end by searching a file of the same type on the disc to be able to open the application. http://bugzilla.gnome.org/show_bug.cgi?id=312399 -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Window managers and their desktop files
-> Window managers and their desktop files desktop-devel-list -- Thread -- -- Date -- <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Thomas Thurman Re: Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Dan Winship Re: Window managers and their desktop files Matthias Clasen Re: Window managers and their desktop files Dan Winship Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Thomas Thurman Re: Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Dan Winship Re: Window managers and their desktop files Matthias Clasen Re: Window managers and their desktop files Dan Winship Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Thomas Thurman Re: Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Dan Winship Re: Window managers and their desktop files Matthias Clasen Re: Window managers and their desktop files Dan Winship Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Thomas Thurman Re: Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Dan Winship Re: Window managers and their desktop files Matthias Clasen Re: Window managers and their desktop files Dan Winship Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Thomas Thurman Re: Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Dan Winship Re: Window managers and their desktop files Matthias Clasen Re: Window managers and their desktop files Dan Winship Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_a
Window managers and their desktop files
-> Re: Window managers and their desktop files desktop-devel-list -- Thread -- -- Date -- <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Thomas Thurman Re: Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Dan Winship Re: Window managers and their desktop files Matthias Clasen Re: Window managers and their desktop files Dan Winship Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Thomas Thurman Re: Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Dan Winship Re: Window managers and their desktop files Matthias Clasen Re: Window managers and their desktop files Dan Winship Reply via email to
Window managers and their desktop files
-> Re: Window managers and their desktop files desktop-devel-list -- Thread -- -- Date -- <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Thomas Thurman Re: Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Dan Winship Re: Window managers and their desktop files Matthias Clasen Re: Window managers and their desktop files Dan Winship Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Thomas Thurman Re: Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Dan Winship Re: Window managers and their desktop files Matthias Clasen Re: Window managers and their desktop files Dan Winship Reply via email to
Window managers and their desktop files
-> Re: Window managers and their desktop files desktop-devel-list -- Thread -- -- Date -- <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Thomas Thurman Re: Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Dan Winship Re: Window managers and their desktop files Matthias Clasen Re: Window managers and their desktop files Dan Winship Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Thomas Thurman Re: Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Dan Winship Re: Window managers and their desktop files Matthias Clasen Re: Window managers and their desktop files Dan Winship Reply via email to
Window managers and their desktop files
-> Re: Window managers and their desktop files desktop-devel-list -- Thread -- -- Date -- <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Thomas Thurman Re: Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Dan Winship Re: Window managers and their desktop files Matthias Clasen Re: Window managers and their desktop files Dan Winship Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "8427791634"; google_color_border = "FF"; google_color_bg = "FF"; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Thomas Thurman Re: Window managers and their desktop files Patryk Zawadzki Re: Window managers and their desktop files Dan Winship Re: Window managers and their desktop files Matthias Clasen Re: Window managers and their desktop files Dan Winship Reply via email to
