Is there any way to set the window icon to something other than the default? I mean the one that appears in the top left corner of the window's title bar, and in the task bar.
If not, can I put in a feature request for that?
Paul
Good idea.
Cas :)
Been awhile since this was requested :cry:
I've taken the liberty to implement this on windows. MacOS port is trivial as it uses awt. I leave it up to someone else to do the linux port.
Anyway, it seems I've gotten this to work on windows. Windows has 2 icon sizes. The big icon is used when alt-tabbing between application, the smal icon is used in the frame caption, and the taskbar. I've added 2 functions: setSmallWindowIcon and setBigWindowIcon. I'd like to keep the 2 functions even if they are not used on Mac or linux. Is more professional than haveing one of the icons scaled.
There is no need for a getMin/MaxSize, as windows and awt will accept icons of any size. It is better to have getRecommendedSmallIconSize and getRecommendedBigIconSize functions to allow the lwjgl application to privede the icons that has the closest fit.
I can post the code here in the forum or I could mail it to someone with cvs access. I don't want to commit to cvs directly as it will take me too long to set up. It would be a good idee if someone that knows windows/c programming has a look at the code, as I'm sure it has bunch of resource leaks in it :oops:
awesome!
send it to info@lwjgl.org and I'll take a look at it. We might refactor the code as needed though.
Quote from: "Matzon"awesome!
send it to info@lwjgl.org and I'll take a look at it. We might refactor the code as needed though.
Sure, do what you like with it. The code is in the mail.
If the Mac port is trivial because it uses awt, would the Linux port also not be trivial? Or am I missing something here?
BTW, great job on the Windows icon! :)
I think linux does all it's own window managment, and do not use awt.
I think Elias has rewritten it all to use AWT now on Linux.
Cas :)
Did not know about that. I just looked at the 0.96 source.
In that case the linux port will be trivial as well.
Ah, no. Linux Display uses AWT locking to synchronize with AWT because X11 is not multithread safe. The rest of the code is still custom X11 (except AWTGLCanvas support of course)
- elias
I was going to look at doing the linux version, but we need to decide on the API. Since each of the platforms require different size icons (16x16 and 24x24 for windows, 16x16 upwards for linux, and preferably huge for MacOS) we need something beautifully generic.
A suggestions:
public class Display {
public static final int ICON_16 = 1;
public static final int ICON_24 = 2;
public static final int ICON_32 = 3;
public static final int ICON_64 = 4;
public static final int ICON_128 = 5;
public static void setIcon(int type,ByteBuffer data) {
// each Display implementation decides whether it wants to use
// this icon size or not, if not the default or previously set icon is
// maintained
// assumed RGBA8 - if not the implementation is responsible
// for filtering
}
}
Kev
Why the type then? - if the data is RGBA8 then just check the size of the passed buffer?
I was thinking it let people who were using it know what sizes it would be good to provide. But yeah, I see your point.. maybe the javadoc could say enough?
Kev
So, what ya reckon? On IRC we've talked about some sort of wrapped object (org.lwjgl.Image?) that holds the byte buffer, validates it and handles conversions for platform specifics.
I've got linux code that seems to work now, so we just need an API :)
Kev
Lets recap how icons are handled on the different systems and try to come up with a sensible api that enables all the available features, but keeps the api simple.
On windows there are:
-BigIcon, size 32x32, used when alt-tabbing between apps.
-SmalIcon, size 16x16, used in window titlebar and taskbar.
The image used can be of any reasonable size (think there is limit around 4096*4096). The image will be scaled with bilinear filtering to 32x32 or 16x16 by windows. Only tested on windows xp. Don't know if other icons sizes are in use on other windows version/setup.
MacOs:
Because it uses AWT only one icon can be used threw setIconImage(Image image). I assume that the image will be resized by awt to the prefered size on MacOS. Can anyone try to find out what the prefered size of the icon is on MacOS?
Can you give a description of how icons works on linux, kevglass?
I don't see the need for a org.lwjgl.Image class. Just document that the pixels need to be tighly packed and format of the pixel (ARGB or RGBA). Width and height are passed in as arguments to the functions.
Yeah, an icon on linux is just a pixmap, which basically means it can be anysize, but it appears 32x32 is traditional.
Kev
Quote from: "kevglass"Yeah, an icon on linux is just a pixmap, which basically means it can be anysize, but it appears 32x32 is traditional.
Kev
But there is only one icon size used by the application?
What about tha api I suggested before:
int getRecommendedSmallIconSize()
int getRecommendedBigIconSize()
setSmallIcon(int data[], int width, int height)
setBigIcon(int data[], int width, int height)
Big icon is only used in windows when alt-tabbing. Otherwise small icon is used. The image passed in can be of any size, but it will be scaled if it don't fit the recommended size.
Its fine by me, just like to get a standardised API sort so we can get something in. However, Small and Big doesn't really make sense. In this case what we're really saying is:
setWindowIcon()
and
setWinAltTabbingIcon() :)
--
Also, this API means that I'll have ot put an OS check into my code to set the right size of icon, 16x16 on window, 32x32 on linux and up-to 128x128 on macos. :(
Kev
I am still fond of the:
/**
* Sets one or more icons for the Display.
* <ul>
* <li>On Windows you should supply at least one 16x16 icon and one 32x32.</li>
* <li>Linux (and similar platforms) expect one 32x32 icon.</li>
* <li>Mac OS X should be supplied one 128x128 icon</li>
* </ul>
* The implementation will use the supplied ByteBuffers with image data in RGBA and perform any conversions nescesarry for the specific platform.
*
* @param icons Array of icons in RGBA mode
* @return number of icons used.
*/
public int Display.setIcon(ByteBuffer[] icons);
I see no reason for adding getMin/Max since these are known ahead of time. And in that same sense - one might argue the same with cursor...
Looks good to me, OOI why return the number icons used?
Kev
QuoteI see no reason for adding getMin/Max since these are known ahead of time. And in that same sense - one might argue the same with cursor...
That is fine by me as long as it is fairly certain that there will never be any other sizes than 16, 32 and 128.
Quotepublic int Display.setIcon(ByteBuffer[] icons);
I think this is too unclear. I think it would be better to set by type or have 3 functions:
public int Display.setIcon16x16(ByteBuffer iconData, int width, int height);
public int Display.setIcon32x32(ByteBuffer iconData, int width, int height);
public int Display.setIcon128x128(ByteBuffer iconData, int width, int height);
The javadoc would make it clear that the functions would scale the image if it don't fit.
Quote from: "kevglass"Looks good to me, OOI why return the number icons used?
if setIcon == 0, then an error occured - avoids the need for exceptions
QuoteI think this is too unclear. I think it would be better to set by type or have 3 functions:
Code:
public int Display.setIcon16x16(ByteBuffer iconData, int width, int height);
public int Display.setIcon32x32(ByteBuffer iconData, int width, int height);
public int Display.setIcon128x128(ByteBuffer iconData, int width, int height);
The javadoc would make it clear that the functions would scale the image if it don't fit.
The problem with this, is that it's bloat
ish and I really prefer a cleaner api by not doing like cocoa (for example stringByAbbreviatingWithTildeInPath style method calls).
And forwarding a bit into the future, we would have 7 setIcon methods because of ports... whereas using 1 method would just require an updated javadoc
I am also a bit undecided whether or not an implementation should scale the images supplied, instead of forcing the developer to pass correct data. The former can lead to ugly icons and/or unexpected behaviour, wheread the latter will lead to the expected behaviour, but mean that the dev have to supply proper icons (which IMO is a good thing).
Quote from: "Matzon"Quote from: "kevglass"Looks good to me, OOI why return the number icons used?
if setIcon == 0, then an error occured - avoids the need for exceptions
Why avoid exceptions? I'd like to know when something went wrong :shock:.
- elias
Exceptions are for tadaaa - exceptions!
if you supplied invalid icons sizes for specified platform then thats not an exception, it just means that the icon couldn't be used, thus 0.
If you passed something that couldn't be used (can't see how that would happen, since its just bytes) then thats an exception and will be thrown, but thats probably a runtime exception more than anything.
Passing in byte buffers who size didn't give a square would be an exception circumstance. Or buffers that were empty I guess.
Kev