[Fedora-packaging] desktop file icon/pixmap locations

Chuck Anderson cra at WPI.EDU
Tue Jul 8 02:33:14 UTC 2008


On Mon, Jul 07, 2008 at 10:06:28PM -0400, Tom Lane wrote:
> Chuck Anderson <cra at WPI.EDU> writes:
> > Where should icons for desktop files be stored?  Some packages use 
> > /usr/share/pixmaps.  Others use subdirectories under 
> > /usr/share/pixmaps (some directories are unowned too).  Some use a 
> > private directory under /usr/share/<name>.  Still others use 
> > /usr/share/icons/.
> 
> Red Hat's rpmdiff tool has recently started to complain if desktop
> icon files are not underneath /usr/share/pixmaps/, so apparently there
> is policy to that effect somewhere.  Unowned directories are certainly
> verboten too.  I have no idea if there's any existing policy about your
> other questions.

Do you mean rpmlint?  It seems most are under /usr/share/icons, so the 
tool should probably be updated if that's true.

> One point: I'd suggest that we *not* require conversion of upstream
> icon files to a uniform file format, so long as what upstream supplies
> will work (ie, please no "thou shalt convert xpm to png" in the
> guidelines).  Doing that would require BuildRequire'ing some image
> conversion package or other, which seems like a pretty heavyweight
> build dependency for hardly any real gain.

Ok, some more mystery behind this.  There are several sets of 
utilities to deal with icons and desktop files:

gtk2:

/usr/bin/gtk-update-icon-cache

desktop-file-utils:

Summary     : Utilities for manipulating .desktop files
Description :
.desktop files are used to describe an application for inclusion in
GNOME or KDE menus.  This package contains desktop-file-validate which
checks whether a .desktop file complies with the specification at
http://www.freedesktop.org/standards/, and desktop-file-install
which installs a desktop file to the standard directory, optionally
fixing it up in the process.

xdg-utils:

Summary     : Basic desktop integration functions
Description :
The xdg-utils package is a set of simple scripts that provide basic
desktop integration functions for any Free Desktop, such as Linux.
They are intended to provide a set of defacto standards.
This means that:
*  Third party software developers can rely on these xdg-utils
   for all of their simple integration needs.
*  Developers of desktop environments can make sure that their
   environments are well supported
*  Distribution vendors can provide custom versions of these utilities

The following scripts are provided at this time:
* xdg-desktop-menu      Install desktop menu items
* xdg-desktop-icon      Install icons to the desktop
* xdg-icon-resource     Install icon resources
* xdg-mime              Query information about file type handling and
                        install descriptions for new file types
* xdg-open              Open a file or URL in the user's preferred application
* xdg-email             Send mail using the user's preferred e-mail composer
* xdg-screensaver       Control the screensaver

I was about to think "oh, xdg-utils must be the replacement/superset 
of desktop-file-utils + gtk-update-icon-cache".  It seems xdg-utils is 
being used by KDE[1] but not GNOME[2].  And Oo.org isn't using 
desktop-file-install but it is using gtk-update-icon-cache[3].

So my question is, in what direction is all of this stuff going, and 
what should I use for my package[4] which just has two simple .xpm 
icons, one of which is referenced by a relative path in the .desktop 
file?  I need to fix the relative path becuase desktop-file-install 
doesn't like it, but the question is, how should I fix it?

[1] 
http://cvs.fedoraproject.org/viewcvs/devel/kdebase/kdebase.spec?rev=1.333&view=auto

[2] 
http://cvs.fedoraproject.org/viewcvs/devel/gnome-applets/gnome-applets.spec?rev=1.288&view=auto 
http://cvs.fedoraproject.org/viewcvs/devel/gedit/gedit.spec?rev=1.157&view=auto

[3] 
http://cvs.fedoraproject.org/viewcvs/devel/openoffice.org/openoffice.org.spec?rev=1.1567&view=auto

[4]
https://bugzilla.redhat.com/show_bug.cgi?id=452749




More information about the packaging mailing list