Re: [AD] Proposal for a set_icon function |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
>That's exactly what the user currently does, isn't it ? Using a Windows icon
>designer program, creating the resource file, compiling it and linking the
>object file. So basically we wouldn't do anything except adding
>win_set_icon() (2 lines of code) ?
>
>My proposal simply aims at freeing the user from the Windows specific part
>of the process: he could use his Allegro bitmaps to generate the program
>icon very easily.
>
>> for other OSes this function could change (and of course be on their own
>> OSdependant header), so the user could do
>
>I don't think the functions could share the same name since they wouldn't
>have the same prototype.
At this point, what's the problem with adding a normal set_window_icon(BITMAP
*icon) function to Allegro, shared by all ports? Adding a Win32 specific
function only to change the window icon doesn't make much sense to me, as
other ports would need something very similar too... The BeOS problem (to the
newcomers, the problem is that when you change the icon of a program at
runtime in BeOS, the new icon gets attached to the exe, and remains there
even after the program exits) isn't really a bad issue, and could be handled
as an exception, clearly stated in the docs. Other ports should make the
set_window_icon function to behave the normal way whenever possible - i.e.
set the window icon at runtime, leaving the exe icon untouched.
And if you want to add a script to set the Win32 exe icon resource from an
Allegro bitmap, IMHO this could be done and shipped within Allegro, but
should not affect the above function, and it should be stated in the docs.
just my 2c...
--
Angelo Mottola
a.mottola@xxxxxxxxxx
http://www.ecplusplus.com