Proposal for update to packaging guidelines for icon files
kevin.kofler at chello.at
Wed Jan 11 23:03:12 UTC 2012
Richard Shaw wrote:
> 1. If installing icons into in to /usr/share/pixmaps is indeed
It's not installing into /usr/share/pixmaps which is deprecated, but the
whole concept of unthemed, fixed-size icons.
> Then we need to update the packaging guidelines for the Desktop Files
> section. In the "Icon tag in Desktop Files" section it explicitly shows
> a full path to an icon file in /usr/share/pixmaps.
Because that's the standard path for unthemed, fixed-size icons.
> While not intended as a guideline, it should be revised to showing a
> full path to an icon in /usr/share/icons/hicolor
No. It makes no sense whatsoever to reference /usr/share/icons/hicolor with
an absolute path!
The guideline should instead be changed to make it clear that using an
absolute path there is deprecated and the other method should be preferred.
> (probably in the 48x48 directory since it's the minimum requirement.)
That is just a suggestion, not a requirement. For example, KDE Plasma
doesn't actually use 48×48 anywhere, it uses 32×32 in Kickoff and 16×16 in
the classic menu, so if you're designing for Plasma, having only a 48×48
icon is suboptimal.
> 2. It may even be better to create a separate section for icons.
> Because the guidelines require us to "Requires:" a package when we
> install a file into a directory that the package does not own,
> theoretically all packages that install icons into
> /usr/share/icons/hicolor need to "Requires: hicolor-icon-theme". This
> should probably be explained more directly.
Not just theoretically, but pratically. This is a MUST requirement.
The whole purpose of hicolor-icon-theme is to be required by any package
which installs any icons. It contains no actual icons, but just an empty
theme for applications to install their icons into. Any application
installing icons to hicolor MUST Require hicolor-icon-theme. Packages not
doing that must be fixed.
More information about the devel