windowscodecs: Use Mac OS X native ICNS support, not libicns.

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

windowscodecs: Use Mac OS X native ICNS support, not libicns.

Ken Thomases
Hi Damjan,

I was intrigued to see the ICNS support you added to windowscodecs some months ago.  Neat work!

However, I'm confused about why you used the third-party libicns library.  As near as I can tell, the ICNS support is only used on Mac OS X and it's not likely to ever be used elsewhere.  If that's the case, why did you not build it on top of the native ICNS support built into Mac OS X?  Using the native frameworks would avoid one more external dependency that would need to be shipped with Wine on the Mac.

I'm attaching a patch that changes to using the ApplicationServices framework instead of libicns.  I wanted to get your input before sending it to wine-patches.  What do you think?

Thanks,
Ken

-----------------------------------------------------------------------

The ICNS support is only used on Mac OS X and is not anticipated to be used
on any other platform.  So, we can rely on the native frameworks rather than
a third-party dependency.
---
configure.ac                    |   16 +--
dlls/windowscodecs/Makefile.in  |    1 +
dlls/windowscodecs/icnsformat.c |  270 ++++++++++++++++-----------------------
include/config.h.in             |   10 +-
4 files changed, 119 insertions(+), 178 deletions(-)




0002-windowscodecs-Use-Mac-OS-X-native-ICNS-support-not-l.patch (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: windowscodecs: Use Mac OS X native ICNS support, not libicns.

Damjan Jovanovic-2
On Wed, Jan 5, 2011 at 1:04 PM, Ken Thomases <[hidden email]> wrote:
> Hi Damjan,
>
> I was intrigued to see the ICNS support you added to windowscodecs some months ago.  Neat work!

Thank you.

> However, I'm confused about why you used the third-party libicns library.  As near as I can tell, the ICNS support is only used on Mac OS X and it's not likely to ever be used elsewhere.  If that's the case, why did you not build it on top of the native ICNS support built into Mac OS X?  Using the native frameworks would avoid one more external dependency that would need to be shipped with Wine on the Mac.
>
> I'm attaching a patch that changes to using the ApplicationServices framework instead of libicns.  I wanted to get your input before sending it to wine-patches.  What do you think?

Alexandre wanted ICNS writing to be done using windowscodecs, and I
don't have access to a Mac so I didn't know about any alternative.

It doesn't seem like a good idea to introduce a platform-specific
dependency for ICNS support, but you might want to get feedback from
other Wine developers.

By the way, as for your other patch, freedesktop also supports
multiple icon sizes, but it uses a strange directory structure to do
it which I haven't quite gotten to work yet.

Thank you
Damjan


Reply | Threaded
Open this post in threaded view
|

Re: windowscodecs: Use Mac OS X native ICNS support, not libicns.

Ken Thomases
On Jan 5, 2011, at 5:25 AM, Damjan Jovanovic wrote:

> It doesn't seem like a good idea to introduce a platform-specific
> dependency for ICNS support, but you might want to get feedback from
> other Wine developers.

Hmm.  I guess I don't see how ICNS is anything other than platform-specific.  Is it used anywhere else?  Is it ever expected to be?


> By the way, as for your other patch, freedesktop also supports
> multiple icon sizes, but it uses a strange directory structure to do
> it which I haven't quite gotten to work yet.

OK.  Do you think my patch should be held up until you find an approach that works for both?

Thanks for your quick reply!

-Ken



Reply | Threaded
Open this post in threaded view
|

Re: windowscodecs: Use Mac OS X native ICNS support, not libicns.

Damjan Jovanovic-2
On Wed, Jan 5, 2011 at 1:31 PM, Ken Thomases <[hidden email]> wrote:

> On Jan 5, 2011, at 5:25 AM, Damjan Jovanovic wrote:
>
>> It doesn't seem like a good idea to introduce a platform-specific
>> dependency for ICNS support, but you might want to get feedback from
>> other Wine developers.
>
> Hmm.  I guess I don't see how ICNS is anything other than platform-specific.  Is it used anywhere else?  Is it ever expected to be?
>
>
>> By the way, as for your other patch, freedesktop also supports
>> multiple icon sizes, but it uses a strange directory structure to do
>> it which I haven't quite gotten to work yet.
>
> OK.  Do you think my patch should be held up until you find an approach that works for both?

The patch seems fine (doesn't seem to regress anything), but aren't
ICNS files invisible anyway with winemenubuilder writing .desktop
files which MacOS can't use?

> Thanks for your quick reply!
>
> -Ken
>
>

Damjan


Reply | Threaded
Open this post in threaded view
|

Re: windowscodecs: Use Mac OS X native ICNS support, not libicns.

Ken Thomases
On Jan 5, 2011, at 5:45 AM, Damjan Jovanovic wrote:

> On Wed, Jan 5, 2011 at 1:31 PM, Ken Thomases <[hidden email]> wrote:
>> OK.  Do you think my patch should be held up until you find an approach that works for both?
>
> The patch seems fine (doesn't seem to regress anything), but aren't
> ICNS files invisible anyway with winemenubuilder writing .desktop
> files which MacOS can't use?

Well, yes, the ICNS files are not currently used.  Still, things get improved bit by bit.  :)

Besides being referenced by .desktop files which aren't used, the ICNS files are written to /tmp, as things stand.

-Ken



Reply | Threaded
Open this post in threaded view
|

Re: windowscodecs: Use Mac OS X native ICNS support, not libicns.

elus89
I suggest passing this on to the devs of wineskin, a mac-based wine wrapper.  Perhaps it could be added to a subsection of winetricks, too.  It would need to be thoroughly tested of course...

I am very much a newbie.  But, if you have some bug-testing you need a guinea-pig for, and a well-written set of instructions, I'm available.

Also, ICNS is already implemented in Wine?  Or what's the status if I needed to access it myself?