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/.
Icon=/usr/share/sane/xsane/xsane-logo.xpm
rpm -ql gnome-utils | grep /usr/share/pixmaps
/usr/share/pixmaps/gsearchtool/thumbnail_frame.png file /usr/share/pixmaps/gsearchtool is not owned by any package
How should the icon be referred to in a desktop file? Some use absolute paths, others no path at all. desktop-file-install complains if there is a relative or partial path.
Icon=/usr/share/system-config-lvm/pixmaps/lv_icon.png Icon=/usr/share/system-config-selinux/system-config-selinux.png
Some desktop file icons don't use an extention, but some do:
Icon=accessories-calculator Icon=accessories-dictionary.png
It looks like the majority of the desktop files on my F9 system are using the form without an extension.
All of this is confusing. For new applications, what should they use? What are the semantics for the various syntaxes that are used? What should be done for upstream packages that have icons? What if they are in xpm format rather than png?
Thanks.
Chuck Anderson cra@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.
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.
regards, tom lane
On Mon, 2008-07-07 at 22:06 -0400, Tom Lane wrote:
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).
I'm pretty sure that png and xpm are supported at a minimum, possibly other formats as well.
~spot
"Tom "spot" Callaway" tcallawa@redhat.com writes:
On Mon, 2008-07-07 at 22:06 -0400, Tom Lane wrote:
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).
I'm pretty sure that png and xpm are supported at a minimum, possibly other formats as well.
Hmmm ... using file(1) on an F-8 workstation I find this under /usr/share/pixmaps and /usr/share/icons:
141 ASCII text (.theme and .icon extensions) 229 GLS_BINARY_LSB_FIRST (no idea what these are) 19 JPEG 8890 PNG 1 TIFF 12 TrueType font data (icon-theme.cache files) 16 X (.xpm) 686 XML (.svg) 236 gzip (.svgz)
How many of these icons actually work as expected is an interesting question, but clearly there's a variety of formats that packages *think* are supported. PNG is by far the majority though, and it looks like the usages of the stranger formats are confined to a few packages each. Maybe we *should* standardize on PNG here --- it appears that only a few packages would be affected by a conversion requirement.
regards, tom lane
On Mon, 2008-07-07 at 22:44 -0400, Tom Lane wrote:
"Tom "spot" Callaway" tcallawa@redhat.com writes:
On Mon, 2008-07-07 at 22:06 -0400, Tom Lane wrote:
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).
I'm pretty sure that png and xpm are supported at a minimum, possibly other formats as well.
Hmmm ... using file(1) on an F-8 workstation I find this under /usr/share/pixmaps and /usr/share/icons:
[snip]
How many of these icons actually work as expected is an interesting question, but clearly there's a variety of formats that packages *think* are supported. PNG is by far the majority though, and it looks like the usages of the stranger formats are confined to a few packages each. Maybe we *should* standardize on PNG here --- it appears that only a few packages would be affected by a conversion requirement.
SVG is also definitely a reasonable alternative to png -- it gives scalable icons which will be more important as we begin to get devices with resolutions on both the high and the low end of the spectrum
Jeremy
On Mon, Jul 07, 2008 at 10:06:28PM -0400, Tom Lane wrote:
Chuck Anderson cra@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&am...
[2] http://cvs.fedoraproject.org/viewcvs/devel/gnome-applets/gnome-applets.spec?... http://cvs.fedoraproject.org/viewcvs/devel/gedit/gedit.spec?rev=1.157&vi...
[3] http://cvs.fedoraproject.org/viewcvs/devel/openoffice.org/openoffice.org.spe...
Chuck Anderson cra@WPI.EDU writes:
On Mon, Jul 07, 2008 at 10:06:28PM -0400, Tom Lane wrote:
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.
Do you mean rpmlint?
No, I meant rpmdiff, which is an internal tool that vets RPMs in various ways (principally, but not solely, by comparison to the previous release of the package --- hence the name). I got blindsided by the /pixmaps check recently while rebuilding unixODBC for RHEL-5, so I'm quite sure this is a new policy ...
regards, tom lane
On Mon, 2008-07-07 at 22:33 -0400, Chuck Anderson wrote:
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.
Supported formats for themed icons are xpm, png and svg. Thus, if you install the icon below /usr/share/icons/hicolor/ it should be in one of those formats. If you install it in /usr/share/pixmaps, it can really be anything, but traditionally, that directory is for xpms. In the desktop file, the icon should be either specified as a full path (including extension) or as an icon name (without extension), the latter being preferred.
Matthias Clasen mclasen@redhat.com writes:
Supported formats for themed icons are xpm, png and svg. Thus, if you install the icon below /usr/share/icons/hicolor/ it should be in one of those formats. If you install it in /usr/share/pixmaps, it can really be anything, but traditionally, that directory is for xpms. In the desktop file, the icon should be either specified as a full path (including extension) or as an icon name (without extension), the latter being preferred.
I guess the appropriate question for this list is "where is all that documented?"
regards, tom lane
On Mon, 2008-07-07 at 23:43 -0400, Tom Lane wrote:
Matthias Clasen mclasen@redhat.com writes:
Supported formats for themed icons are xpm, png and svg. Thus, if you install the icon below /usr/share/icons/hicolor/ it should be in one of those formats. If you install it in /usr/share/pixmaps, it can really be anything, but traditionally, that directory is for xpms. In the desktop file, the icon should be either specified as a full path (including extension) or as an icon name (without extension), the latter being preferred.
I guess the appropriate question for this list is "where is all that documented?"
http://standards.freedesktop.org/desktop-entry-spec/latest/ is the spec describing .desktop files
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html is the spec describing icon themes
On Tue, Jul 08, 2008 at 12:29:15AM -0400, Matthias Clasen wrote:
On Mon, 2008-07-07 at 23:43 -0400, Tom Lane wrote:
Matthias Clasen mclasen@redhat.com writes:
Supported formats for themed icons are xpm, png and svg. Thus, if you install the icon below /usr/share/icons/hicolor/ it should be in one of those formats. If you install it in /usr/share/pixmaps, it can really be anything, but traditionally, that directory is for xpms. In the desktop file, the icon should be either specified as a full path (including extension) or as an icon name (without extension), the latter being preferred.
I guess the appropriate question for this list is "where is all that documented?"
http://standards.freedesktop.org/desktop-entry-spec/latest/ is the spec describing .desktop files
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html is the spec describing icon themes
Thanks for the pointer. I've decided to follow this spec for installing upstream's xpm icons into /usr/share/icons/hicolor/{16x16,48x48}/apps.
packaging@lists.fedoraproject.org
-
Chuck Anderson -
Jeremy Katz -
Matthias Clasen -
Tom Callaway -
Tom Lane