On Tue, Nov 5, 2013 at 9:57 AM, Saether Jan-Arve <jan-arve.saet...@digia.com> wrote: > > Is there any big benefits in having ICNS support on other platforms than OSX? >
I can comment a bit about my own use of the plugin. The ICNS icon engine from the code review in my initial mail is used in Mumble (http://mumble.info/) on OS X (and only OS X) to display icons from appliactions on the system (you can add applications to a black/white list for Mumble's overlay feature). That's the extent of its use in Mumble. So my own use of the icon engine is restricted to OS X. As such, my own use of the engine could just as well be satisfied by having an ICNS icon engine in QtMacExtras (or wherever) that wraps NSImage - or some native code in Mumble to load the icons via native APIs. Let's take a step back... Having access to ICNS via QIcon on OS X would be very convenient for Qt applications that need to integrate with native apps somehow. (For example, a Web IDE providing a drop-down of available browsers on the system, or obviously the Mumble use-case mentioned earlier). So the question is, how do we implement such a thing? My proposed implementation is an icon engine that only depends on Qt functionality, and as such can work on any platform that Qt supports. The unfortunate thing about it is that access to icons in the ICNS container that have sizes greater than 128x128, we need a JP2K decoder. (This check happens at runtime. If no jp2k decoder is present, a QIcon with only the smaller sizes available is returned to the caller.) When I wrote the engine a couple of years ago, that seemed to be the best approach, and the "Qt way", if you will. All the pieces were available in Qt (JP2K was available as separate component, but still available). Another implementation strategy could be, as I mentioned previously, a wrapper around the native frameworks. It would only run on OS X, but it would not need the JasPer dependency to access the full range of icons. Back when I did my implementation, there was no QtMacExtras (Qt 4!), so perhaps that's why it didn't seem very Qt-like to wrap the native frameworks for an icon engine. I don't know what the general feeling on that subject is now. It might be the sensible thing to do. >From what I can see, though, the real blocker here is the JasPer dep. I wholeheartedly agree that including JasPer as a dependency just for an icon engine seems like a rather insane requirement. But if there are other users of the JP2K image format, then I don't see why a native wrapper would be preferred for an icon engine over a Qt-native solution that's able to run and be tested across all platforms. (Also, it's worth noting that the JP2K image format is not a hard dependency. For many use cases, including mine, displaying a small icon in a dropdown or list view might be sufficient - and the JP2K image format might not be needed at all. In fact, I'm not even building the JP2K image format myself at present - I only display the small variants of the .icns.) I am obviously also not opposed to just keeping it out of the Qt tree like I've been doing previously. It just seemed like something that would be useful for others to have . :-) (And other seem to agree. The reason I'm upstreaming the code is because Jake Petroules had wanted ICNS support In Qt, and was considering writing an icon engine for it himself. Instead, he found mine and asked me whether I was interested in submitting it upstream...) Mikkel _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development