Bug 146484 - Workspace switcher applet icons doesn't always match theme icon
Workspace switcher applet icons doesn't always match theme icon
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Andrew Overholt
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-28 14:21 EST by Stephen R. Saucier
Modified: 2008-08-02 19:40 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-03 15:00:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Stephen R. Saucier 2005-01-28 14:21:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
Window icon for eclipse uses the square purplish stock eclipse icon
and not the redhat-artwork provided eclipse icon.

This makes things inconsistent as I launch the program from a menu
item which uses one icon and then it appears using a separate one.

Version-Release number of selected component (if applicable):
eclipse-gtk2-3.0.1_fc-9

How reproducible:
Always

Steps to Reproduce:
1. Applications->Programming->Eclipse (uses redhat-artwork icon)
2. Once launched, notice the stock eclipse icon in the window selector
panel applet, for instance.

Actual Results:  Noticed inconsistent icons. (Eclipse stock icon)

Expected Results:  I should have seen the redhat-artwork eclipse icon
located in /usr/share/icons/Bluecurve/48x48/apps/eclipse.png for example.
Comment 1 Stephen R. Saucier 2005-02-03 15:11:26 EST
I believe the icon associated with eclipse while it is running is
located in plugins/platform-launcher/bin/linux/*/icon.xpm so if this
icon were replaced during the build I think it would fix the problem.
Unfortunately, I don't know enough details about the way gtk icons are
handled in order to suggest a theme-independent mechanism to
accomplish the correct behavior.
Comment 2 Stephen R. Saucier 2005-02-09 11:15:46 EST
Actually, I'm not sure that this is exactly the issue; I think the
issue is a more general one of modifying eclipse to use the icon
specified in the current gtk theme (or I guess defaulting to the
original purplish one if none exists for the current theme) Maybe this
should be filed upstream to the eclipse gtk maintainers?
Comment 3 Rick Moseley 2005-02-23 15:26:42 EST
Actually, this may be handled properly when the RH "Eclipse branding"
plugin is complete and working properly (and maybe not).  Looking at
how Eclipse handles icons, each part of Eclipse(platform, ui, jdt,
cdt, etc.) has its own set of icons and a lot of them are exactly the
same.  Some of them are not even named the same, but are exactly the
same in appearance.  :(  We will see what the next incarnation of the
"branding plugin" brings and if the icon situation is not properly
resolved I have written a ham-handed script that will replace all of
the appropriate icons and hopefully clear this up before we package it
for distribution.  We'll keep the bug open until we figure out what is
going on.
Comment 4 Phil Muldoon 2005-04-05 15:40:44 EDT
No branding plug-in for Fedora Core 4 (technical and space restrictions).
Ideally we need to replace the icons in situ as described above, at least for now.
Comment 5 Andrew Overholt 2005-04-26 12:26:56 EDT
In newer builds (>= 3.1.0_fc-0.M6.9), we're using upstream icons exclusively. 
Please let me know if this is fixed satisfactorily.
Comment 6 Stephen R. Saucier 2005-06-21 20:40:09 EDT
This problem still exists in fedora core 4.

As an aside, this problem also exists in gnome-terminal, last time I checked, so it isn't specific to eclipse.
Comment 7 Andrew Overholt 2005-10-27 16:27:51 EDT
This isn't really an Eclipse issue.  I don't know where to file it.  Let's try
gnome-panel.  Please fix the component if I'm wrong.  I'm also clarifying the
summary.
Comment 8 Alexander Larsson 2005-10-28 04:59:01 EDT
The workspace switcher only displays the icon you set for the window. This is an
actual icon image, not a name, so there is no way the panel can do anything
about it. Handling of themes switches for the window has to be done by the app.

If you use gtk_window_set_icon_name() to set the icon name this will be handled
automatically by gtk+.
Comment 9 Andrew Overholt 2005-11-22 11:12:04 EST
(In reply to comment #8)
> The workspace switcher only displays the icon you set for the window.

As Stephen says in comment #6, this problem isn't Eclipse-specific.  For
example, right now I'm using Bluecurve but the gnome-terminal icon in the
switcher is the stock GNOME icon.  Is this expected behaviour?
Comment 10 Alexander Larsson 2005-11-23 06:17:03 EST
I wouldn't say its expected behaviour. Its more like a bug in gnome-terminal.
Comment 11 Andrew Overholt 2005-11-23 10:21:10 EST
(In reply to comment #10)
> I wouldn't say its expected behaviour. Its more like a bug in gnome-terminal.

It happens with x-chat as well ...
Comment 12 Alexander Larsson 2005-11-25 03:51:10 EST
Here is the deal:

The application is fully in control of what icon it displays, there is nothing
anything else in the desktop can do about it but display the bits that the
application choose as its icon.

From the application side (for gtk apps), if you use gtk_window_set_icon_list(),
gtk_window_set_icon() or gtk_window_set_icon_from_file() you are merely pushing
bits to use as the icon. If these bits where somehow taken from the icon theme
then you need to update it when the icon theme changes (see "changed" signal on
GtkIconTheme). However if you use gtk_window_set_icon_name() to set an icon
based on an icon name in the icon theme, then gtk+ will automatically update the
icon as the icon theme changes.
Comment 13 Stephen R. Saucier 2005-11-28 02:00:42 EST
I understand (as indicated in comment #12) that each application has to use gtk_window_set_icon_name() 
in order for it to exhibit the correct behavior. I assume this means you are suggesting that a bug report 
should be submitted against each affected application (eclipse, x-chat, gnome-terminal, etc.)?
Comment 14 Alexander Larsson 2006-01-12 10:49:07 EST
yes.
Comment 15 Andrew Overholt 2006-02-09 11:23:40 EST
Billy, any thoughts on this?  I see that os.c and OS.java don't use
gtk_window_set_icon_name().
Comment 16 Billy Biggs 2006-02-15 03:59:39 EST
To keep SWT and its libraries small, we try to only include in os.c/OS.java functions
that are actually used in the implementation.  Adding new functions is easy, there are
docs on this linked from the SWT homepage.

Currently, the SWT API only lets you provide a set of images for each top level window.
The concept of application icon theming is specific to Linux/GNOME and it is unclear
to me whether we should provide API for this in SWT.

Eclipse has a system for allowing Eclipse-based applications to provide platform specific
icons, and tooling for managing these.  I believe they are in the org.eclipse.platform
fragment and so if you are changing the Red Hat Eclipse to have different icons, it should
be easy to change there, although they won't update if you change icon themes.
Comment 17 Andrew Overholt 2006-02-27 14:56:26 EST
Thanks for the explanation, Billy.  At this point I don't see this as being a
terribly important issue.  My thoughts are that we should discuss it upstream
if/when we decide it's important.
Comment 18 Igor Foox 2006-03-15 11:58:08 EST
sdfafdasf
Comment 19 Igor Foox 2006-03-15 11:58:24 EST
(In reply to comment #13)
>I understand (as indicated in comment #12) that each application has to use gtk_window_set_icon_name() 
>in order for it to exhibit the correct behavior. I assume this means you are suggesting that a bug report 
adfasdfasdf
>should be submitted against each affected application (eclipse, x-chat, gnome-terminal, etc.)?
Comment 20 Bug Zapper 2008-04-03 11:51:10 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 21 Andrew Overholt 2008-04-03 15:00:34 EDT
I'm satisfied closing this as upstream.

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