Bug 146484

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.

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?

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.

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.

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.

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.

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.

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+.

(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?

I wouldn't say its expected behaviour. Its more like a bug in gnome-terminal.

(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 ...

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.

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.)?

yes.

Billy, any thoughts on this?  I see that os.c and OS.java don't use
gtk_window_set_icon_name().

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.

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.

sdfafdasf

(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.)?

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.

I'm satisfied closing this as upstream.