The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Hi guys,

I'm sure this has been touched on many times before, but I'd like to bring it up again if I may.

In SDL 2.0, setting the window icon with SDL_SetWindowIcon is a nice platform-independent way of doing it, but on Windows it is a pain. Short of editing the SDL source directly, there is no way to instruct SDL to use an icon that is already embedded in the EXE.

I'd like to suggest an API function that takes an icon resource identifier (an integer) specifically for Windows builds:



Alternatively, prior to initializing SDL, you could specify a hint that SDL should use a particular icon resource when it registers window classes:



A third alternative is that SDL should, by default, automatically use the first icon resource in the EXE if there is one is available (this mirrors how Windows Explorer puts icons on EXE files):



The second and third options are probably the easiest to integrate into the current source tree. I'd do this myself, but I'm not an SDL contributor and wouldn't know where to start. I'm interested to hear what the SDL developers think of these suggestions.

Thanks.

Can you create a RWops from the resource?  You can load an SDL_Surface from a RWops (SDL_LoadBMP_RW() or IMG_Load_RW()) and then send it to SDL_SetWindowIcon().  If it's plain pixel data or you know how to decode the format, you can use SDL_CreateRGBSurfaceFrom() directly.

Jonny D

On Wed, Jul 25, 2012 at 3:53 AM, msturner wrote:


I don't like the other two since they involve #ifdef areas and platform-specific stuff, but I think the above idea is a good solution. So few Win32 applications change their icon from the one they have stored in the EXE that I think it'd be safe to do as you suggest below.
 
At this point, the developers are the community, so open season IMO.
 

I think the third solution is good, too.  It would be seamless as far as portability.

However, getting a pointer to the data and using SDL_RWFromMem(), etc. would be more useful.  An interface like that would handle more than just image resources.  With this or the first two suggestions, there would still be a no-op on most (by enumeration) platforms.


Jonny D

While I agree that RWOps would be neat, I suspect that a program that makes extensive use of EXE-embedded resources would likely be inherently less portable than a program that stored its resources in external files and might just choose some #ifdef logic instead. Though if a case can be made for the icon, then why not the mouse cursor etc. It's tough to pick one and exclude the other.

Patrick

On Wed, Jul 25, 2012 at 10:04 AM, Jonathan Dearborn wrote:

Yeah, there may be no clear way to support more platforms through such an interface.  An add-on library that loads resources into RWops would be appropriate, though.

So, I think taking the transparent route (#3) with icons would probably be best, since it is clear enough and there is and has been demand for such a thing.  Automatic and expected is good.  Mouse cursors and more would be useful, but is the demand there or is there a standard for these resources?  They should wait, at the very least.


Jonny D

Not sure if similar facilities exist in whatever language you're using, but in Delphi there's a Resource Stream class for getting access to the data of a resource as a stream, and it's trivial to wrap a SDL_RWops around any stream object. If you have access to a similar resource stream class, that would probably be the best way to go about it.


Mason



From: Jonathan Dearborn
To: SDL Development List
Sent: Wednesday, July 25, 2012 8:04 AM
Subject: Re: [SDL] Windows EXE icon resource


I think the third solution is good, too. It would be seamless as far as portability.

However, getting a pointer to the data and using SDL_RWFromMem(), etc. would be more useful. An interface like that would handle more than just image resources. With this or the first two suggestions, there would still be a no-op on most (by enumeration) platforms.


Jonny D


_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

On Wed, 25 Jul 2012 01:53:01 -0700 msturner wrote:

This is SDL 1.2, but this is what we do in ioq3:

http://svn.icculus.org/quake3/trunk/code/sdl/sdl_icon.h?revision=1416&view=markup

#ifdef USE_ICON
{
SDL_Surface *icon = SDL_CreateRGBSurfaceFrom(
(void *)CLIENT_WINDOW_ICON.pixel_data,
CLIENT_WINDOW_ICON.width,
CLIENT_WINDOW_ICON.height,
CLIENT_WINDOW_ICON.bytes_per_pixel * 8,
CLIENT_WINDOW_ICON.bytes_per_pixel *
CLIENT_WINDOW_ICON.width,
#ifdef Q3_LITTLE_ENDIAN
0x000000FF, 0x0000FF00, 0x00FF0000, 0xFF000000
#else
0xFF000000, 0x00FF0000, 0x0000FF00, 0x000000FF
#endif
);

SDL_WM_SetIcon( icon, NULL );
SDL_FreeSurface( icon );
}
#endif
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi Guys,

Thanks to everyone for your comments.

After thinking about this overnight, and also reading your comments, I agree that option #3 is the overall best solution.
At the very least, it is the solution that would take the least amount of effort to integrate, does not require
refactoring of the API, and would not break existing code.

I do also like the idea of using SDL_SetHint() as a way of tweaking how this operates. For example, you could use it to specify the name of the icon resource to load.

Can I have it by Friday?

Cheers.

One note on resources:




I've played around with embedded resources before, and all that you
really need is a program that transforms a file into a C array filled
with the resource's byte values written in hex, + a variable that
specifies the array's length. The only real restriction is whatever
length limit your compiler places on arrays.

Other platform-specific stuff is, of course, a different topic.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org