Skip to main content

Add a method setIconImages(Image images[]) to [J]Frame, [J]Dialog

4 replies [Last post]
Joined: 2005-07-15

For years there are debates why Java on the desktop doesn't catch on. One reason is that small things (from an engineering point of view) are still not fixed. These small things, however, make it impossible to polish a Java desktop application ad have a huge impact on how end-users perceive such an application: "They can't get this trifle cosmetic thing right, so how will things look under the hood"?

One of the things which are still not satsifying after almost a decade is how top-level window icons can be specified. In detail:

(a) [J]Frame just allows to provide one image via setIconImage(Image icon), which is then scaled in a platform-dependent way. This scaling usually results in rather ugly results if one didn't happen to accidentally provide the right size for a particular platform (this "right size" will of course fail on another platform).

The only solution - read "hack" - for a cross-platform application is to check the OS name on which it is running and select a different icon according to the name. But that hack still doesn't work on platforms where icons of different formats are used by the platform in different places and situations.

So, please make it possible that one can specify a list of potential icons, and the runtime selects these icon(s) from the list which best matches the platform's native icon size(s).

(b) Allow to specify an icon (or better yet the just suggested list of icons) for [J]Dialogs. This is also a feature which people miss for almost a decade in Java.

On platforms or PLAFs where dialogs are not supposed to be decorated with an icon the icon setting should silently be ignored.

(c) Add a method "Dimension[] getPreferedIconSizes()" to [J]Frame and [J]Dialog or the Toolkit, which responds with a list of icon sizes as preferred by the platform.

Such a method would facilitate the use of setIconImages() with a set of matching icons. Note, it should still be allowed to call setIconImages() "blindly" with a set of potentially not matching icons. In this case the runtime should pick the nearest matching icon and scale it to the desired size.

(d) Alternatively, consider adding callbacks to both [J]Frame and [J]Dialog which are called by the frame or dialog when the frame or dialog is in need of some icon. The argument to the callback should be the dimension of the requested icon. A frame or dialog should be allowed to call the registered callback any time, and with different dimensions.

(e) Consider to not only allow arguments of type Image, but also of type Icon.

(f) Consider deprecating the existing setIconImage(Image) method.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-28

Vote, vote, vote, write your comments, submit a specification:

4088703 Need mechanism for displaying platform-sized miniaturized icons
4913618 Dialog doesn't inherits icon from its parent frame

Joined: 2005-07-15

Forget about that voting shit. The voting system is a useless charade.

See for example. See the amount of bugs with just one vote which got fixed? Things are not fixed because of a lot of votes, but because someone at Sun feels like fixing something. And no amount of votes can convince a Sun engineer to fix if he doesn't feel like doing it.

The particular icon bug is seven years old. [b]S-E-V-E-N![/b]. For seven years it is "under investigation". Oh sure yes. The problem is so complex that it for sure requires a couple of PhD thesis' and a million dollar investigation budget to recognize the exact nature of the problem and find a solution. Did someone see Ken Starr recently?

Whenever someone from Sun once more claims that Java's victory on the desktop is imminent and how many new cool features the next Java version will have, then just show him the seven year old bug. It demonstrates Sun's real commitment for real-world desktop Java, as opposite to fancy but useless JFC demo apps.: Zero.

Joined: 2004-05-06

I agree. Usually I assume 32x32 and hope that it looks OK if it has to be scaled. The ability to retrieve preferred icon size(s) would be very useful.

Setting multiple icons, as you said, would be necessary when differently sized icons are used in different places. One issue I can imagine is when a frame border is painted by a Swing L&F and the L&F is then changed. For example, the Metal L&F wants icons at 32x32 when the application starts, and so getPreferedIconSizes() has Dimension element of 32x32 in it. We therefore choose an appropriate icon for this dimension. But then we change to another L&F that wants 48x48 icons, so the 32x32 icon we specified previously will no longer be ideal. Also things like changing OS settings that change icon sizes on the fly could affect this. A callback would solve this problem. Or perhaps a listener added to the frame (PreferredIconSizeListener) that is notified of preferred icon size changes, triggered possibly by either a L&F change or OS settings change.

Joined: 2004-02-03

A callback approach is no doubt the best solution. The reason is this: Some LAFs will on some platforms require only a single icon whereas others will require many. A callback approach will make sure you do not spend time loading or generating icons which are never requested.

Imagine a project where a designer has delivered a single 64x64 icon which you have added to your project. If we had a callback approach you could get lucky that only that single 64x64 icon was requested and you could simply return it. If a 32x32 icon was requested you as a developer could decide whether to support this icon by returning a scaled image or whether to simply return null, if you do not intend to support 32x32 icons. This is simple.

However if you did not have a callback approach you would have to either understand and write specific code for all the different LAFs you could ever encounter (so that XP LAF gets one set of icons, Mac LAF gets another) or you would have to provide a long list of icons, 16x16, 24x24, 32x32, 48x48, ..., to make sure that any icon imagineable was supported - even though they might not ever be requested.

It is important that the design takes into account the fact that scalable vector graphics will be a reality in GUIs one day. The callback interface could look like this:

IconProvider {
SomeFormat getIcon(Dimension size);

Now, if SomeFormat is a type which can be both a pixel graphic and a vector graphic, then this design is forward compatible with the vector graphic future. - An application using SVG can simply ignore the size parameter and return a scalable vector graphic instead.