Swing Hacks

Handling Dropped Picts on Mac OS X #68

Chapter 9, Drag-and-Drop

|

345

HACK

When dropped, you’ll see the image appear in its own JFrame. In Figure 9-5,

I’ve dragged small images from several different applications, resulting in

each being opened in its own frame.

This won’t work if you’re dragging an image from one of the Mac OS X

applications that only supplies one

DataFlavor. You’ll have to deal with Picts

[Hack #68] in that situation.

H A C K

#68

Handling Dropped Picts on Mac OS X Hack #68

For Mac applications that provide only the legacy Pict flavor of drops,

QuickTime for Java offers a Mac-specific solution.

You should already recognize the existence of hard-to-handle DataFlavors

[Hack #67] passed by certain Mac applications. Of the Mac apps I tested, sev-

eral old apps (many using the Carbon APIs, which were developed to migrate

classic Mac apps to OS X) support only one

DataFlavor. When I drop from

GraphicConverter, QuickTime Player, AppleWorks, and MarinerWrite, the

only supported

DataFlavor was reported as:

java.awt.datatransfer.DataFlavor[mimetype=image/x-pict;

representationclass=java.io.InputStream]

Figure 9-4. Dragging an image from a native application to a Swing component

Figure 9-5. Image dropped from a native application and opened in Swing

346

|

Chapter 9, Drag-and-Drop

#68 Handling Dropped Picts on Mac OS X

HACK

For those of you who don’t use Macs, Pict is part of QuickDraw, the origi-

nal Mac graphics API. The term is wildly overloaded—Pict can refer to a file

format, a resource hidden in an application file, a wrapper around vector

drawing commands, and as a wrapper around optionally compressed pixel

data. It’s in this latter form that Pict is a preferred format for passing image

data on the Mac clipboard because Picts are easy for Mac applications to

render and convert (through the QuickDraw library, of course).

Unfortunately, Java doesn’t know the first thing about Picts, so it’s frustrat-

ing to see that Pict is the only supported

DataFlavor

. Worse, the data is sup-

plied as an

InputStream, instead of a file or a URL, meaning you have to

handle it in Java, instead of handing off to non-Java code that might be able

to convert the Pict to something that can handle the format more gracefully.

Fortunately, there is a Java solution to the problem, and it’s called Quick-

Time for Java (QTJ). This API is a Java wrapper around the native Quick-

Time multimedia API. It’s available for Mac OS X and Windows, but since a

Windows application isn’t going to pass you a Pict, you only need to worry

about the Mac OS X case. One advantage of all this API-wrangling: QTJ is

installed by default on Mac OS X, so you can count on it being there.

Everything in this hack is Mac-specific. Since Picts are only

going to be an issue on Mac OS X, don’t bother with this on

programs that you’re sure won’t need to deal with Mac OS X

drops.

First, you’ll need to define a DataFlavor for Pict data in Java input streams:

macPictStreamFlavor =

new DataFlavor ("image/x-pict; class=java.io.InputStream");

Next, take the code from the hack on handling standard dropped images

[Hack #67] and give drop( ) a new else if( ) {...} block to deal with this fla-

vor. This block will use a

QTJPictHelper class, so you need to make that

available (I’ll show you this helper class soon). Since you don’t want to need

to have this class at compile time—that would make life harder for Win-

dows and Linux users, who might not have the QTJava.zip file to compile

against—this code uses reflection to load the

QTJPictHelper class and invoke

its

pictStreamToJavaImage( ):

} else if (trans.isDataFlavorSupported (macPictStreamFlavor)) {

System.out.println ("mac pict stream flavor is supported");

InputStream in =

(InputStream) trans.getTransferData (macPictStreamFlavor);

// for the benefit of the non-mac crowd, this is

// done with reflection. directly, it would be:

// Image img = QTJPictHelper.pictStreamToJavaImage (in);