Bug 101304 - Panel uses theme icon instead of specified one for launchers
Summary: Panel uses theme icon instead of specified one for launchers
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: gnome-panel
Version: beta1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Havoc Pennington
QA Contact:
Keywords: MoveUpstream, Triaged
Depends On:
TreeView+ depends on / blocked
Reported: 2003-07-30 18:45 UTC by Nils Philippsen
Modified: 2007-04-18 16:56 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2003-08-19 06:02:38 UTC

Attachments (Terms of Use)

Description Nils Philippsen 2003-07-30 18:45:44 UTC
Description of problem:

When specifying an icon via a launcher's properties, the panel prefers a
Bluecurve icon with the same name, while the icon shown in the launcher's
properties is the specified one.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Try to set the icon for e.g. Evolution to /usr/share/pixmaps/evolution.png
2. Watch the icon in the properties dialog get the desired one and the icon in
the launcher get the icon with the same name of Bluecurve. 
Actual results:

Wrong icon in launcher

Expected results:

Specified icon in launcher

Additional info:

I could see this with Mozilla, Xchat, even Galeon (which isn't part of RHL
anymore -- why do we ship an icon for it?).

Comment 1 Havoc Pennington 2003-07-30 18:58:21 UTC
I guess we need to not look up in the theme if it's an absolute path, or
something like that...

Comment 2 George Lebl 2003-07-30 20:09:18 UTC
But we explicity kill the path when loading the icon to fix #106649.  This is
very very ugly.

Comment 3 Havoc Pennington 2003-07-30 20:18:17 UTC
desktop file spec extension? there's no back compat extension here though.

maybe the custom icon chooser should only let you pick icons in the theme, 
not arbitrary files...

Comment 4 Nils Philippsen 2003-07-30 22:25:54 UTC
To be frank, that'd be too much "we know what's good for you". The bug isn't
that I can choose an arbitrary icon file, it's that the panel doesn't use it.

Comment 5 Havoc Pennington 2003-07-30 22:37:19 UTC
If the bug isn't fixable we need to remove the unfixable functionality, 
is all I'm saying.

I don't see a good fix due to the compat problem; the file format can be
extended, but not everyone reading the format will understand the extension.

Comment 6 Nils Philippsen 2003-07-30 23:44:15 UTC
Can you elaborate on why the bug isn't fixable? I looked at #100649 (which is
the bug George meant I guess), but I'm still not all that enlightened by reading
through it...

Comment 7 Havoc Pennington 2003-07-31 00:38:00 UTC
I don't understand the relationship to #100649 either, but 
I assume there's some reason absolute paths currently get themed?

If not then it's fixable by not theming those.

Comment 8 George Lebl 2003-07-31 00:52:45 UTC
I forgot to say gnome bugzilla #106649, not redhat bugzilla.  I'm getting lost
in bugzili (is that the correct multiple for bugzillas)?

I don't think it's as bad as unfixable, at least for the panel since we can
extend the panel for the launchers since we're the only ones using those
desktops then.  Unless of course someone dnds it somewhere else of course, then
the icon will change to however the drop location interprets the Icon= field.

Comment 9 Nils Philippsen 2003-07-31 08:44:03 UTC
Looking at gnome BZ #106649, I also think that using the basename of the icon
file is the right thing for DnD (as long as this is done consistently in all
places). In the properties dialog I'm not quite sure -- it could be one of:

- Always use the full path
- Use the full path only when using an icon not from the (current) theme
(potential for confusion when changing themes)
- Let the user choose whether to use "only theme icons" (no "Browse" button,
basename of the icon file) or not (shows Browse button, full path)

What do you think?

Comment 10 George Lebl 2003-08-04 19:18:42 UTC
See what I comitted in gnome CVS, for a somewhat blurry description see


Comment 11 Nils Philippsen 2003-08-19 06:02:38 UTC
Fixed with:


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