Created attachment 413753 [details]
Description of problem:
See attached screenshot, the selinux-polgengui menu entry does not have an icon.
The .desktop file specifies an Icon using a relative path. I believe, like the menu entry for system-config-selinux, it should be an absolute path.
# grep -i icon /usr/share/applications/fedora-*selinux*.desktop
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install policycoreutils-gui-2.0.82-17.fc13
2. Click Applications -> System Tools
* See attached screenshot
* fedora-selinux-polgengui.desktop should use an absolute path to the Icon file.
Works in policycoreutils-2.0.82-22.fc13
(In reply to comment #1)
> Works in policycoreutils-2.0.82-22.fc13
I'm still seeing the problem with policycoreutils-2.0.82-22.fc13.x86_64
# rpm -ql policycoreutils-gui | grep png
In discussion with Dan on IRC, it seems that the Icon file might not be in the right place for GNOME to find it.
I think more work is needed here, based on discussion with Dan Walsh. Moving this back to ASSIGNED. Please adjust if in error.
summary: everything is wrong. =)
to comply with the best practice under the relevant fd.o specs, the icon files should be placed in the appropriate places under the /usr/share/icons/hicolor hierarchy, and the .desktop file should specify only:
no path, and no extension.
"So, You're an application author, and want to install application icons so that they work in the KDE and Gnome menus. Minimally you should install a 48x48 icon in the hicolor theme. This means installing a PNG file in $prefix/share/icons/hicolor/48x48/apps. Optionally you can install icons in different sizes. You might even want to install icons with a look that matches other well known themes so your application will fit in with some specific desktop environment."
Note the format of the default entry, and:
"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 in the Icon Theme Specification will be used to locate the icon."
You *can* specify an absolute path to a particular icon file, but this has drawbacks.
1) no icon theme will be able to specify its own icon for the app, which you really ought to allow for.
2) that single fixed-resolution icon will always be used by anything which reads the .desktop file. What if you specify a really big detailed icon which doesn't scale down well for 16x16 use? What if you specify a small icon which looks ugly and blocky when some shiny new shell wants to display it at 128x128? True, just providing a single icon within the icon theme spec doesn't really solve this either, but it at least leaves open the door for icon theme providers to fix it for you, in their theme. And makes it easier if you _do_ get someone to contribute a properly tailored set of icons at common sizes.
These are the cases which the icon theme system exists to handle. Most Fedora packages follow the conventions recommended by the specs, as I summarized above.
Fedora Bugzappers volunteer triage team
s/default entry/example entry/
Fixed in policycoreutils-2.0.82-26.fc13
Confirmed that the problem is resolved with policycoreutils-2.0.82-26.fc13
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '13'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 13's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 13 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here: