[Development] Moving JP2 imageformat from qt-solutions to qtimageformats

[Mikkel Krautz]

On Tue, Nov 5, 2013 at 9:57 AM, Saether Jan-Arve
<Jan-Arve.Saether at 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