http://bugs.winehq.org/show_bug.cgi?id=25778
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ken@codeweavers.com
--- Comment #5 from Ken Thomases ken@codeweavers.com 2011-01-21 21:39:21 CST --- This has been fixed by http://source.winehq.org/git/wine.git/?a=commit;h=677c1e578d45aafc6886691eebce7ea33ead44c5.
This disables the ICNS support on Tiger. It could be fixed but it's deemed not worth it (by Alexandre and me). Although if somebody were to submit a patch to get it working on Tiger in a way that is fairly clean, it might be accepted.
However, note that the ICNS support is really not used for anything of import currently. winemenubuilder uses it, but doesn't actually do anything useful with the resulting .icns files. They're just written to /tmp and then ignored. So, there's nothing lost by disabling this.
(In reply to comment #4)
- Use ImageIO, a subframework of ApplicationServices that supports reading and
writing a variety of image formats, including icns. ImageIO is available on Mac OS X 10.4; Tiger was in fact the first version to have ImageIO.
When I last tested, ImageIO did not in fact support writing ICNS files. It might have been upgraded to do so since then, but that wouldn't help for Tiger.
- Declare the constants ourselves. The constants follow a pattern. 16x16 is
'ic04', 32x32 is 'ic05', and so on, all the way up to 512x512, which is 'ic09'. If you don't believe me, look up the constants in 10.5/10.6's OSServices and see for yourself. Of course, I have to wonder if Tiger even supports loading 16x16 images from an icns file. In that case, there are other constants (the 'Mini', 'Small', 'Large', and 'Huge' icon types) we can use.
Tiger supports the relevant icon sizes. My code using the IconFamily functions takes advantage of enhancements to the API that allows one to treat sizes smaller than 256x256 as ARGB images. Prior to Leopard, you had to work with the RGB image and the mask separately, which was a pain.
Declaring the constants ourselves would get rid of the compilation error but wouldn't help with functionality. Tiger just won't understand them. I guess going this route would allow for WindowsCodecs to output 256x256 ICNS (and no other size) since that one ARGB size is supported on Tiger.