Community
Participate
Working Groups
1) Lock icon (32 x 32) used in the progress dialog. Currently hacked by Tod 2) Wait icon (16 x 16) used in the progress view. A resize of an old one from the graphics team. Could be much nicer than what I did. 3) Busy view icon. (16 x 16) currently two opposing arrows hacked by Tod in photoshop. We may also need an animated version of this. 4) Progress icon (32 x 32). A lot of discussion has happened around this. I think a round spinner is the preferred choice
*** Bug 44000 has been marked as a duplicate of this bug. ***
suggestion from 40974: The icon for the Problems view should not include a red X. Developers used to using Eclipse have trained themselves to look for red X's as problems that need to be fixed. I would suggest inventing an alternative icon.
*** Bug 40974 has been marked as a duplicate of this bug. ***
tod: in comment #0, 2) can you attach a screen shot of this icon? is it the progress tree item icon, or the animated one? 3) will this be a decorator for the view's normal icon? 4) where is this used? (i just want to make sure you really want it 32x32, as i thought this round spinner was a replacement for the animated 16x16 icon)
Created attachment 8350 [details] Waiting icon
2)I have attached the waiting icon. The problem I have is that it looks OK like this but it is not rendering well. It is used n the progress tree. It is currently 13 x 13 and would be better if it were 20 x 20 so that is the same size as the progress icons. 3) No. It will replace it. 4)It is at the bottom of the screen (the cigarette). Well spotted though Chris - it is 20 x 20.
from nick edgar: "Any plans to update the product icon for the new look?"
initial submission has been made to the design team, including a digest all comments in this PR so far. i will post the response from design team when it arrives. continue with further comments here as necessary to be given to the design team during review cycles.
Tod, please answer the following questions from the designer. I will attach a screenshot for you to help you decode the icon numbers. For 3a, could you attach a screenshot to this PR For 3b(i), I expect the 32x32 is for the dialog, do we also need the 13x13. Questions: 1. So we should continue with the production of all icons marked with an asterix? 2. I've changed the date for you, I'm not sure why that didn't work. 3. a. Could you send me screencaptures of where the icons you mentioned occur in the UI, and what they currently look like?. b. I believe that we've included them in this request, but could you confirm... (i). 13 x 13 Lock icon (146?), (ii). 20 x 20 wait icon (141? - ours is at 13 x13, but you would prefer 20x20?), (iii) 16 x 16 busy view icon (not sure if this one has been included) (iv) 20 x 20 progress icon (149?) c. We also seem to be missing a visual for #150... do you know what is currently being used for this icon?
Created attachment 8370 [details] progress icons
veronika: question from icon designer regarding hot vs. normal vs. disabled states. as per our discussion with linda, they are not sending us a 'hot' version of any icon. we are going to simply use 'normal' for the hot state. is that cool with you? the designer was also wondering if we could rely on the platform to derive the icon to express the disabled state from the normal icon. is this fine as well? provided i do not set a disabled icon, will the button automatically derive a disabled icon from its normal icon to show when the button is in the disabled state? are there any caveats here (for instance in widgets other than button)?
Just remembered one more - the progress view is currently using an Eclipse icon and needs one that is not product specific.
Janet Mockler/Toronto/IBM wrote on 03/05/2004 03:25:04 PM: ...Also, would it be possible to deliver all of the Workbench icons in one plug-in directory, for instance "org.eclipse.ui" rather than splitting them up into 6 different directories? Or are the separate directories important to maintain?... Nick replied: With the RCP split, we need to maintain separate icon directories for org.eclipse.ui (any icons in the generic workbench), org.eclipse.ui.ide (anything ide-specific, including Navigator and marker views), and org.eclipse.ui.views (outline or properties views icons). Right now there's a lot of duplication between org.eclipse.ui and org.eclipse.ui.ide because the ide directories were initially just duplicated for simplicity, and we haven't yet done the pruning. There's a PR open for this.
141 is to be 20 x 20 (same as the 147) 142 is obsolete and can be deleted 143 should be 20 x 20 (same as the 147) 144 is obsolete and can be deleted 145 is to be 20 x 20 (same as the 147) 146 is to be 32 x 32 (same as info and error gifs) 147 is to remain 20 x 20. 148 should be 20 x 20 149 is 16 x 16 (as you say) 150 is blank because it is the gif we draw when nothing is running. It needs to be the same size as 147
If you only set the one image (using setImage()), then there will be no hot image and the platform will generate a disabled image. There is a slight chance that the algorithm that drains colors from an image will behave poorly. That is why some applications set both images. In any case, you can ditch the hot image.
up to date with the design team for all comments thus far. did one round of critiquing of the icons. teleconferenced with linda watson regarding disabled state: in our shared view, the right thing to do is allow the platform to generate the disabled icon. therefore. sometime between now and when the first set of icons is supplied (this can be done anytime) i will ensure that calls to setDisabledImage etc. in the ui plugins are commented out.
In the new look, will we be keeping with monochrome icons except for hot images?
I've checked in changes to HEAD in the org.eclipse.ui.* plugins to explicitly remove setting disabled or hover icons. I need someone running XP and/or W2K with UI from HEAD (mvm, nick, or tod) to add to this PR some screenshots of the toolbar showing some disabled icons. A third useful screenshot would be XP running the 'windows classic' look (not exactly the same as W2K). For completeness, it would be nice to see a hover over an enabled icon in the screenshots, though i'm pretty sure the platform doesn't do anything special to the icon in this case. Eventually, other teams will need to make the same changes in their plugins that I made this morning, i.e: searching for setDisabledImage, setHotImage, setDisabledImageDescriptor, setHoverImageDescriptor in their Java code, searching for disabledIcon and hoverIcon in their plugin.xml files, and commenting out as appropriate.
This is a huge code change requirement for large products like WSAD. Can we not just change how ActionContributionItem uses the configured images?
MVM posted a preliminary screenshot of new icons here: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/R3_0-Look/3.0workbench_icons.png Attached is the comments I've received thus far.
Created attachment 8664 [details] Icon Critique
I need a new icon for the new wizard menu (and potentially other places as well) that shows a help balloon. I'd like it at the path: icons\full\elcl16\linkto_help.gif I'll attach a gif of what I'd like. This is a copy from the cheetsheet plugin.
Created attachment 8686 [details] What I'd like
It will be difficult to get the right disabled look on Windows by taking color icons and running them through either the win XP default disabled code OR SWT disabling code. I will attach the following snaps taken to show how things look with the latest icons (shipped March 16 or so).
Created attachment 8689 [details] Win XP standard disabling style
Created attachment 8690 [details] Win XP running SWT disabling style
Created attachment 8691 [details] all icons on WinXP SWT and standard Win XP disabled
I'd also like to request icons for activities and activity categories. icons\full\obj16\activity.gif icons\full\obj16\activity_category.gif I'm not sure what these should look like... but I'll attach a screen cap of the dialog where they'll be used.
the ui plugins have been updated with the first drop. 1. the design team needs to ship icons in the 'e' directories instead of the 'c' directories. ('e' means enabled (the normal icon state). 'c' specifically means 'color', but they are really used for 'hover' or 'hot' icons, something we are no longer using. ideally, the 'c' should really be dropped altogether from the nomenclature because distinguishing color vs. non-color is not important. distinguishing disabled vs. normal vs. hot/hover state is important). 2. the following icons are missing drop (or it hasn't been requested that the design team manage): org.eclipse.ui and org.eclipse.ui.ide: icons/full/obj16/blank.gif - a blank.gif, 16x16, necessary as a spacer in tables. icons/full/obj16/welcome_banner.gif - i will attach this. used in dialog banners. icons/full/elcl16/linkto_help.gif - kim has attached this. icons/full/etool16/next_nav.gif - similar to forward_nav/backward_nav, but a down arrow icons/full/etool16/prev_nav.gif - similar to forward_nav/backward_nav, but an up arrow icons/full/dlcl16/* - all disabled versions of the icons icons/full/dtool16/* - all disabled versions of the icons 3. disabled versions of the icons are missing from all plugins in the drop, and it looks from the evidence that like we will need the design team to produce these after all.
Created attachment 8692 [details] /icons/full/obj16/blank.gif
Created attachment 8693 [details] /icons/full/obj16/welcome_banner.gif
nick edgar had the following critique (from bug 55336) (Platform default) disabled state: The Save and Print toolbar buttons are almost completely invisible when disabled. The disabled state of the Back and Forward arrows also look poor. The Up icon in the Navigator and Package Explorer: is disproportionately small compared to the left and right arrows. The fat arrows: take some getting used to. I think the old ones were more elegant, and less distracting.
*** Bug 55336 has been marked as a duplicate of this bug. ***
*** Bug 55037 has been marked as a duplicate of this bug. ***
*** Bug 42017 has been marked as a duplicate of this bug. ***
Created attachment 8694 [details] The dialog in question
Tod, please answer the following questions from the designer and attach screenshots to this PR. Thanks.. 1. Progress icons (icons 12/147/151): resolution? are we including them in the request, or are we using the native progress bar. My assumption is that we need to produce a View icon (12) that emulates the look of the native progress bar. Please provide a screencapture. 2. Progress icons: update: need screencaptures to show where they sit. (icons 141-150) 3. Popup dialogue box (referencing new icon request: Lock icon 32 x 32) : please send a screencapture of the UI element that it will be located within. To help us understand the requirement a bit better.
The icon we have is fine for the progress view as this is the icon used in the entries. I will attach the other screen shots
Created attachment 8708 [details] The lock image in a dialog
Created attachment 8709 [details] Problems view with progress
design team has full summary of all issues thus far. we expect another drop before Monday March 22 at 2p. (among many other changes, this drop will include disabled versions of the icons)
received another icon drop with correct files and paths, committed everything. added back in the setting of explicit disabled images, though it seems as if in many cases we are not setting an explicit disabled image when we could be and instead are relying on the platform default disabled image. ***before closing this bug we should search for all setImage calls and ensure we are setting the equivalent setDisabledImage, after all we have explicit images for these. similarly for plugin.xml declarations - use the disabledIcon attribute in all possible cases.*** i am asking the visual design team to ensure a disabled icon for every enabled icon (a one-to-one filename correspondance between 'e' dirs and 'd' dirs..), even if some disabled icons aren't used right now. removed all internal hover/hot image setting in java and plugin.xml. there are no more 'c' dirs. references in code has been updated to reflect this, and for those few cases where there is public API for paths to hover images (ISharedImages for instance), the paths are redirected to 'e' dirs. darin has been given the drops and migration instructions for externaltools and console; kai for editors and workbench.texteditor
Some work done for M8, to finish in M9.
Another one needs to be added (see Bug 55892). We need an icon for progress groups (there currently is not one). A progress group is a grouping of related jobs. We could use the same icons as progress but I am not sure this is the right answer.
How are disabled images being supplied in M8? They seem to be just B&W versions of the color images. I find it hard to tell which icons are disabled. Wouldn't SWT generate "etched" versions of the transparency mask for disabled??
Ed Burnette had the following critique, I beleive based on the link in comment #20: The left, right, up, down, undo, and redo yellow arrows are a bit thick. They look more blob-y than arrow-y. I can't tell which way they're pointing as easily as the old ones. This is not helped by the lighter border being used in the new icons. The new, save, print, import, and export icons are too washed out, and they look less native on Windows. I thought they were disabled until I saw the really disabled versions which are almost invisible. The new icons for open and closed folders are too washed out. The CVS decoration is less visible on top of it because the icon is lighter, and they look less native on Windows. The collapse-all icon isn't used consistency. Navigator uses the new one and Package Explorer uses the old one. Sometimes the running man is black and sometimes he's blue? I don't get the distinction. The pin editor icon is unclear because I can't see the pin. The icon for plain text files is hard to see in the editor tabs. I think it's a problem with the border not being a solid black color like the one for Java and other files. To see this, edit plugin.properties (which uses a nice solid border) and .classpath (which uses the washed out border) and compare them side by side. The former is much more visible.
a new drop has been placed in the build tonight, and all comments/requests thus far (from outside of this pr as well) have gone to the design team.
I'd like to request two new icons. 1) A "Theme element category" icon. This icon will be used in a tree viewer to categorize colors and fonts. I envision this icon being the standard folder icon with some kind of decorator (perhaps an "F" for fonts or a small color ball). (/full/obj16/theme_category.gif") 2) A "Font" icon. This will be used in the same tree viewer to distinguish font items. I envision the uppercase/lowercase F combination that is often used to indicate fonts. (/full/obj16/font.gif)
Kim, for comment #48 please attach an image of the latest color and font edit page with circles around #1 and #2 to indicate where these fonts will be and what their application is, this helps clear up usage a lot
Chris, I tried out the nightly build N20040404 and found that we are not using disabled icons in menus when menu items are disabled. Is this the intended behaviour. attaching a pic of what we do vs apps that use them.
Created attachment 9224 [details] greyed menu items
SWT only supports one image on MenuItem. On Win2K, it does give them a disabled appearance when the item is disabled (except when you hover over the item).
Created attachment 9284 [details] Visual of comment #48
The "new" decorator icon looks more like one of the gems from bejeweled. I think it is supposed to be a + sign, but it looks like a diamond to me.
Created attachment 10031 [details] "Run" icon is now "Play"? Is that an icon of an Imperial Star Destroyer? No, it's a triangle with line through it, with another triangle on top of it, just like on a VCR. Nothing quite says "Run" like "Play".
Randy this is a bug report for the UI team to communicate our requirements to the designers. Please direct comments like comment #54 and comment #55 to me directly (as noted on the mailing list) with some constructive suggestions that way your opinions have the best chance of making a difference.
The JDT team has a single bugzilla where the community is providing feedback. bug 56769. UI could take that approach (which is how I *mis*interpreted this bugzilla) or we could open bugzillas on each icon. The problem with personal e- mail, besides not being open, is that if the receiver disagrees with the feedback, it might get lost.
(mid-air collision corrected)
Has there been any movement on the icons I requested in #48?
*** Bug 60877 has been marked as a duplicate of this bug. ***
Kim - Your request has been received and added to our design production stream. MVM will likely be in touch with you when the icons are ready.
I'd like to request another icon. We'd like to have an icon for Introduction extensions that do not provide their own icon. This icon would have to be entirely generic - ie: no eclipse/SDK imagery. This would reside in org.eclipse.ui/icons/full/eview16/intro.gif Screen cap forthcoming.
Created attachment 10311 [details] Intro icon I'm not sure what would be a good generic "Introduction" indicator...
Re comment #18. For products building on Eclipse, no code changes should be necessary to get colour icons. However, it is likely that the graphic design for the icons would need to be updated to be less bright and saturated, for consistency with Eclipse SDK icons. There are different design constraints when colour in icons is used only when hovering over the item, rather than having the icons always be in colour. If the app sets the "hover" variants for actions (IAction.setHoverImageDescriptor), this will now be used for the regular enabled image as well. The regular image set by IAction.setImageDescriptor will be ignored if setHoverImageDescriptor is also set. If no hover variant is set, the regular image will be used, and will not be converted to gray scale. This behaviour is controlled in JFace via ActionContributionItem.setUseColorIconsInToolbars(boolean). The default in JFace is true. The Workbench overrides this default with a preference setting. The setting for this default is now true (it was false in 2.1). In 2.1, the user had the ability to turn on colour icons in the Appearance preference page. In 3.0, this preference has been removed. If an app wants the 2.1 behaviour, this can be achieved by adding the following line to the plugin_customization.ini file of the app's primary feature: org.eclipse.ui.workbench/COLOR_ICONS=false
Few considerations about icons... 1- delete icon: these are just few examples, not a complete review. In M8 the delete icon in "Package Explorer" and "Tasks" context menus become a big "gray X" while in "Error Log" still was a big "red X". Now in M9 things reversed, "Package Explorer" and "Tasks" again have a "red X" while "Error Log" has a "gray X". I don't understand the logic behind this, but, historically, in Windows something grayed in a menu or a toolbar, means a disabled entry and that is exactly the feeling i have when i look at that "gray X". I think red gives more the impression that you are about to perform an irreversible action. And if any rule dictate not to use red, why not resort using the color of the X icon in tabs when you hover on it with the mouse? But, please, don't use gray in a context of colored icons. 2- I like the design of new icons, but IMHO many of them looks too much like a dollar bill after many hot temperature cycles in a washing machine. I have observed that if you have a crisp LCD monitor, you can still, with some effort, distinguish the details, but with many old CRT monitors, where color focus is no more perfect, they look irremediably blurred. This was not happening with old icons. Thanks, for your attention, Gabriele.
Created attachment 11045 [details] Delete and remove icons Gabriele - Thanks for your comments. re: 1 - For this release we brought more cohesion between the delete and remove concept. The distinction between the red and black X corresponds to delete and remove. The disabled version of these icons is distinct in treatment. re: 2 - Between M8 and M9 we have cripsed the majority of the icons for clearer recognition. We hope this is satisfactory.
The jface project refers to an image org/eclipse/jface/viewers/images/dots_button.gif that didn't exist. I found it in /org.eclipse.ui/icons/full/obj16/dots_button.gif and it was not being used by ui. The image should be moved from the ui project to the jface project.
see bug 46576 for information on the re-org of icons between RCP and the Workbench
3.0 icons are done
