Community
Participate
Working Groups
To state my bias up front, I work a lot on Ubuntu, and have noticed the "platform" or "sdk" does NOT have "emblems" displayed, when windows are "scaled", but, I've noticed, that EPP packages DO have emblems displayed. I'll provide screen shots soon, to illustrate, for those not familiar with the concept for environment. Through too much trial and error, I've noticed that the only difference between "EPP packages" and base eclipse, is that in their "product" plugin.xml files, they specify exactly 3 png images as "windowImages" .... whereas we have a long list. I think this won't effect other platforms, in that windows uses the "ico" file for such images, and Apple uses this icns file. I do not know what other linux distributions use, but can't imagine it'd "hurt" them ... and may help? In fact, I'd like to go beyond EPP, and specify 32 bit, 48 bit, and .. I guess 128 bit. It seems the 48 bit one is the one used for "emblems" but having the 32 bit be "first in the list" causes a "scaled down" version to be used in the "about" menu action, which to me, looks slightly better than the 16 bit png image (has a touch of orange in it, without looking too blurry, to my eyes). I think part of the issue is that we may not use the sophisticated "look up" heuristics that other "Linux Apps" use. For example, see http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html I've tried to "get it to work" by using that spec, but nothing I did would get it to work. This is important, to be and other Linux/Ubuntu users in that the "emblems" do increase productivity when a lot of windows open, and/or many instances of Eclipse used.
Adding Arun to CC in case a "better way" is known, or if, eventually, SWT could do more to follow the guidelines? But, not sure how universal these guidelines are ... such as not sure if RedHat uses them? I can attach "xprop" output, if that'd help SWT team.
Created attachment 241967 [details] desktop in "scaled" mode to show all open windows Notice how all windows have a "emblem" displayed in lower right hand corner, except for our standard "SDK" (from Luna) bottom row, second from right. Next image with show Eclipse only.
Created attachment 241970 [details] Eclipse only windows scaled. There's ways to display "all windows" (super-w) as I have defined, but another feature is to display only those from a certain class, by clicking on the "launcher" button for Eclipse on left (this launcher button is not "built in" or automatic, but many blogs and documentation on how to create them. (I'm using Ubuntu 12.04 ... hopefully will be easier, more integrated with 14.04?) At any rate, this shows only the 4 eclipse windows I have open. One "Juno Java EE package" with "WTP-like" logo for emblem, Another is Kepler "standard" EPP package with previous release icon as emblem, the one with no emblem, is our current SDK, which has 8 or 10 images displayed in "window images", a mix of png and gif files. The one with new Luna logo displayed is a "test build" I did with only three images in "windowsImages" list, which shows it correct displays the 48 bit image as emblem. Makes navigation to the desired Eclipse instance much easier.
http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=6dc501e759d03b7a9e14caba781f7ff84072e75d Actually, decided to have 16, 32, and 48 bit in "binary platform" and 32, 48, and 128 in "SDK". I think either will solve the "emblem problem" but be easer to see effects else where such as on about menu item or "window icon" itself, if any. I'm open to changing so they "match" (have same set) but think it'd be helpful to see difference "built it". Note, I am leaving other images (such as the icon.xpm, and gif images, and png images of all sizes) and to some extent, users can change what's used "after installed", but it'd not easy to change, due to caching effects. The windowImages list much be changed after extracted, but before "first run" or else user has to figure out how to clear the cash in metadata runtime data ... which I never really figured out how to do safely. Adding Markus to CC, so he can be on the look out for if this effects EPP packages or not ... but ... I think since I'm following EPP example, that it would not.
Created attachment 242003 [details] Windows N20140414-2000 This looks bad on Windows in N20140414-2000. The missing 16px icon is visible in the Help > About menu item, and the application icon in the window title bar and in the task bar are scaled versions (blurred and with the orange C on the left).
I've reverted the change with: http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=ee5772f3b9734415d0c8e47e3e01223d70cf8fec Deleting certain sizes of the icon and rely on the OS resizing another icon is not the right approach. I assume the designers didn't add the "orange" to the 16x16 icon because there's just not enough space to make it look good. If we want to fix this, then the designers have to provide a new and sharp 16x16 icon. BTW: I noticed that two new formats got added: eclipse24.png,\ eclipse22.png,\ but I don't think anyone uses them.
David, if Shell#setImages(..) makes problems on GTK, then please file a bug for SWT.
(In reply to Dani Megert from comment #6) > I've reverted the change with: > http://git.eclipse.org/c/platform/eclipse.platform.git/commit/ > ?id=ee5772f3b9734415d0c8e47e3e01223d70cf8fec > > Deleting certain sizes of the icon and rely on the OS resizing another icon > is not the right approach. I assume the designers didn't add the "orange" to > the 16x16 icon because there's just not enough space to make it look good. > If we want to fix this, then the designers have to provide a new and sharp > 16x16 icon. > > BTW: I noticed that two new formats got added: > eclipse24.png,\ > eclipse22.png,\ > but I don't think anyone uses them. Thanks for testing. Not sure if you had time to test binary platform, but I'd still like to change to 16, 32, 48 -- sorry to have experimented with I-build (forgot it'd would be "coming up". But, the 16, 32, 48, matches what EPP packages do, and seems to work there. They also explicitly set 'windowImage' to the one that's 16x16. In earlier experiments, windows appeared to use what was in ico file, or what was built in to executable. I'll check build with some tools we have ... we (Tyhco) might be replacing the ones in executable ... not sure if there is a way to prevent that ... and now that I look at it, even the eclipse.ico in git appears corrupt. That's the one at /org.eclipse.equinox.executable/library/win32/eclipse.ico which should be "built in" to windows executable. Sigh ...
(In reply to David Williams from comment #8) ... and now that I look at it, even the eclipse.ico in git > appears corrupt. That's the one at > /org.eclipse.equinox.executable/library/win32/eclipse.ico > which should be "built in" to windows executable. > Never mind, it appears fine ("investigation" documented in bug 432848).
I've confirmed the issue on Windows, with the "experimental" set, but also confirmed that it does not effect the ico embedded in the executable. Hence, I think we re safe going with 16, 32, 48 PNG images. If anyone knows of an issue with that, please say, otherwise, I think it's worth "fitting in" to the way EPP does things (and making a much more usable version for linux users, at least, Ubuntu).
http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=c5a13288a81a2e99c4fb873c23ac2fd82187a438
(In reply to David Williams from comment #11) > http://git.eclipse.org/c/platform/eclipse.platform.git/commit/ > ?id=c5a13288a81a2e99c4fb873c23ac2fd82187a438 What is your expert background to decide that the other formats are not required/used by any platform? I am still -1 for this change, but if you provide a sound technical explanation that no platform needs them I'll not revert the change.
Retitled to state the issue in terms of a problem, not merely one solution. So, if anyone knows of other/better solutions, feel free to say. I am reluctant to say this is an SWT problem, because I doubt its "set images" was made for such a long list of mixed format images. And, I know of no reason for it to. Again, if others know how and why so many images of mixed format must be in the list, please feel free to re-open. To answer Dani's question, I'm not that familiar with aix, s390, or hp, but, for many years used only 3 sizes, and the "specs" (or guidelines) I am familiar with, specifies PNG format (with SVG) optional. http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html I know sparc still specifies the "pixmap" format, but we have always provided those in the distribution, but not in the property "windowsImages". http://docs.oracle.com/cd/E19683-01/806-7492/creatingicons-20497/index.html If anything, we may need 24 bit and 96 bit PNG images for "full use" in GNOME applications. https://developer.gnome.org/hig-book/stable/icons-types.html.en#application_icons Even the last time this was done, for Juno, it was suggested the about.box image be converted to PNG (bug 341645 comment 35) but seems it was never done. And from that Juno bug, it appears Windows XP was the only thing that ever needed a 64 bit image ... which I'm assuming is no longer on our supported platforms list. To summarize, I am trying to solve a "known problem" rather than just sticking with that we have, which is outdated. If anyone knows of other problems, feel free to say. Oh, and BTW, I Arun was the first person I added to the bug, thinking he'd know requirements of (modern versions) of the rarer platforms.
Here's a nice overview: www.visualpharm.com/articles/icon_sizes.html You see that each icon is used by one or the other platform. Does your change really fix the Linux problem? If so, then there is really a bug in SWT if it used the 16x16 GIF but now not the 16x16 PNG. Note that with your fix, the orange shadow is still not present under Windows 7. Did we ask the designer to provide a sharp 16x16 image with the orange shadow? If not, I think that's what we should do in order to get the same look/icons on all platforms. I can live with removing the GIFs but would prefer to add the larger variants (eclipse64.png,eclipse128.png,eclipse256.png) back.
(In reply to Dani Megert from comment #14) > Here's a nice overview: > www.visualpharm.com/articles/icon_sizes.html Thanks for the reference. I see where it's slightly outdated, since for example, in Apple's documentation,see https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Optimizing/Optimizing.html#//apple_ref/doc/uid/TP40012302-CH7-SW3 it says = = = = There is no longer a 1024x1024 size. That’s replaced by 512x512@2x. = = = = (which, I suspect in practice, 512x512@2x is merely a 1024 pixel image, but, it need not be exactly the same as what would have been the 1024 sized image -- though I did use that in in forming the 512x512@2x image for our Mac ICNS image ... which Sileneo did confirm for me "looks ok" on retina display. But your reference is useful. Unfortunately, it calls for many sizes we do not provide ... or, at least don't provide so far. > > You see that each icon is used by one or the other platform. > > Does your change really fix the Linux problem? If so, then there is really a > bug in SWT if it used the 16x16 GIF but now not the 16x16 PNG. To document this properly, it is bug 430137 that showed the GIF image was being chosen over the PNG image, if GIF list first in the list of "windowImages". Besides bug 430137 I've documented this in bug 424916 and, no offense, but I think SWT has the information they need to open their own bug, if this surprises them, since my "problem" was solved by changing the order, not sure what I'd open a bug about ... other then "Dani said to" :) > > Note that with your fix, the orange shadow is still not present under > Windows 7. Did we ask the designer to provide a sharp 16x16 image with the > orange shadow? If not, I think that's what we should do in order to get the > same look/icons on all platforms. The Orange shadow was really a side issue in this bug, sorry to have confused that issue with "the emblem" problem, which I meant to be what this bug is about. And, yes, we did ask designer for orange shadowed 16x16 image, many times, and made several attempts ourselves, and from community, and the "final response" is best exemplified in bug 426260 comment 93, to quote: = = = = = = Otherwise, I'd love to see the icon improved and the orange introduced. However, I am not sure if the graphic designer I use will be able to do it. I think it needs to be someone closer to the product who can incrementally include a new graphic version to see what it looks like. = = = = = > > I can live with removing the GIFs but would prefer to add the larger > variants (eclipse64.png,eclipse128.png,eclipse256.png) back. I did try "the full list" of PNG images, and it did not solve the emblem problem ... sort of like list of windowImages was not made to handle so many images? At least for all platforms. I can experiment with other combinations, such as adding back 1 or 2 of them? But, I'd feel better having concrete problems to solve, since there are known problems that are pretty bad, that will take some time consuming "hand editing", such as bug 429915, bug 432791, and 429914 to name a few I think are higher priority, 6 additional ones listed as "blocking" the main graphics bug 426260. And, again, I'll point out that EPP has had a "list of three" for many years, so I think that pretty well covers Windows, Mac, and Linux. Many of the other platforms, AIX, s390, hpux, solaris, are more "server machines" and I doubt have higher graphics requirements. One complication, I think, is knowing exactly when Tycho, or PDE, actually uses the images in "windowImages" to "overlay" what is already in windows executable. So, if acceptable to you, I've opened bug 432910 so these issues can be prioritized with the other known "graphics bugs". And if you have any suggestions on the priorities of many bugs still open for the new graphics, I'm sure you won't be shy in letting me know. Thanks again,
I20140415-0800 and N20140415-2000 look good on the Mac. AFAICS, the windowsImages are not actually used, since the Mac doesn't have per-window icons, and Eclipse.app/Contents/Resources/Eclipse.icns is used as app icon and for "emblems", etc.
Verified in I20140422-0800 that emblems show in platform and SDK, "out of the box" on Ubuntu 12.04. (I'm in process of installing Ubuntu 14.04, since that LTS version just came out ... already I can tell they are likely to have "raised the bar" ... for example, on 12.04, 32x32 was smallest size of launcher icons ... on 14.04 you can "scale down" to 16x16! In other words, SVG may be "requirement of the future"?]. [FWIW, over the weekend, I tested "by hand" adding only eclipse256.png to the list (for 4 total) and it did not work ... that is, emblem was again, not displayed). Of course, "order" might matter, or something ... but, from http://www.visualpharm.com/articles/icon_sizes.html it seems that each platform (and/or platform version) really should have it's own "windowImages" list ... not sure if there is anyway to accomplish that, with current system.]
