Bug 591897 - selinux-polgengui has incorrect Icon path in .desktop file
Summary: selinux-polgengui has incorrect Icon path in .desktop file
Alias: None
Product: Fedora
Classification: Fedora
Component: policycoreutils
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-13 12:55 UTC by James Laska
Modified: 2013-09-02 06:49 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-06-02 14:10:40 UTC
Type: ---

Attachments (Terms of Use)
Screenshot (93.09 KB, image/png)
2010-05-13 12:55 UTC, James Laska
no flags Details

Description James Laska 2010-05-13 12:55:41 UTC
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):
* policycoreutils-gui-2.0.82-17.fc13.x86_64

How reproducible:

Steps to Reproduce:
1. Install policycoreutils-gui-2.0.82-17.fc13
2. Click Applications -> System Tools
Actual results:

* See attached screenshot

Expected results:

* fedora-selinux-polgengui.desktop should use an absolute path to the Icon file.

Additional info:

Comment 1 Daniel Walsh 2010-05-25 17:17:19 UTC
Works in policycoreutils-2.0.82-22.fc13

Comment 2 James Laska 2010-05-25 18:10:00 UTC
(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.

Comment 3 James Laska 2010-05-25 18:16:14 UTC
I think more work is needed here, based on discussion with Dan Walsh.  Moving this back to ASSIGNED.  Please adjust if in error.

Comment 4 Adam Williamson 2010-05-25 21:18:30 UTC
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.

Ref: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html

"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

Comment 5 Adam Williamson 2010-05-25 21:18:58 UTC
s/default entry/example entry/

Comment 6 Daniel Walsh 2010-06-02 18:56:17 UTC
Fixed in policycoreutils-2.0.82-26.fc13

Comment 7 James Laska 2010-06-02 19:09:08 UTC
Confirmed that the problem is resolved with policycoreutils-2.0.82-26.fc13 


Comment 8 Bug Zapper 2011-06-02 14:05:30 UTC
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: 

Note You need to log in before you can comment on or make changes to this bug.