|Summary:||Workspace switcher applet icons doesn't always match theme icon|
|Product:||[Fedora] Fedora||Reporter:||Stephen R. Saucier <ssauci1>|
|Component:||eclipse||Assignee:||Andrew Overholt <overholt>|
|Status:||CLOSED UPSTREAM||QA Contact:|
|Version:||rawhide||CC:||alexl, billy.biggs, dmalcolm, triage|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-04-03 19:00:34 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Stephen R. Saucier 2005-01-28 19:21:05 UTC
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 20:11:26 UTC
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 16:15:46 UTC
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 20:26:42 UTC
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 19:40:44 UTC
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 16:26:56 UTC
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-22 00:40:09 UTC
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 20:27:51 UTC
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 08:59:01 UTC
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 16:12:04 UTC
(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 11:17:03 UTC
I wouldn't say its expected behaviour. Its more like a bug in gnome-terminal.
Comment 11 Andrew Overholt 2005-11-23 15:21:10 UTC
(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 08:51:10 UTC
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 07:00:42 UTC
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 15:49:07 UTC
Comment 15 Andrew Overholt 2006-02-09 16:23:40 UTC
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 08:59:39 UTC
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 19:56:26 UTC
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 16:58:08 UTC
Comment 19 Igor Foox 2006-03-15 16:58:24 UTC
(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 15:51:10 UTC
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 19:00:34 UTC
I'm satisfied closing this as upstream.