Custom iMedia pasteboard types

[Mike Abdullah]

I'm tracking down a variety of problems with drag and drop in iMedia, and it brought up the question:

iMedia places onto the pasteboard — when dragging or copying — these custom types:
kIMBPasteboardTypeObjectsPromise
kIMBPublicTitleListPasteboardType
kIMBPublicMetadataListPasteboardType
I'm curious, how many of us are actually using these types when in our apps when reading from the pasteboard?

[Peter Baumgartner]

Old versions of FotoMagico (3.x) still use kIMBPasteboardTypeObjectsPromise. The rest I never used.

BTW, iMedia3 uses none of the above, it has a completely new, modern drag & drop architecture and only drags individual items. The items contains both an IMBObject and an NSURL.

[Mike Abdullah]

So iMedia 3 has given up on file promises then?

In actually having a chance to test this stuff, our custom pasteboard formats worry me simply because other apps on the system can’t make use of them. Sure, if third parties adopted iMedia, that would be grand, but Apple are *never* going to do so for their apps.

[Peter Baumgartner]

Hi Mike,

IMBObjectsPromise has become obsolete in iMedia 3 for 2 reason:

1) iMedia 3 only uses the most modern dragging API available (NSDraggingItem and NSPasteboardItem with associated protocols). The hodge podge of old APIs that is still present in iMedia 2 was compeltely eliminated.

2) The sole reason of existence for IMBObjectsPromise was an additional abstraction layer for media that isn't available locally and needs to be fetch asynchronously after a drag has concluded. Think of Flickr as an example. IMBObjectsPromise provided an abstraction layer that made Flicker and Finder or iTunes look exaclty the same from an API point of view. Since iMedia 3 has been completely redesigned to be asynchronous via XPC services anyway, this additional layer of abstraction was not longer necessary!

That's why we simply got rid of the class. BTW, drag & drop related code in the framework is reduced to about 25% now. The new APIs work a lot better and are much easier to understand!

Peter

[Mike Abdullah]

On 29 Oct 2012, at 15:52, Peter Baumgartner wrote:

Hi Mike,

IMBObjectsPromise has become obsolete in iMedia 3 for 2 reason:

1) iMedia 3 only uses the most modern dragging API available (NSDraggingItem and NSPasteboardItem with associated protocols). The hodge podge of old APIs that is still present in iMedia 2 was compeltely eliminated.

2) The sole reason of existence for IMBObjectsPromise was an additional abstraction layer for media that isn't available locally and needs to be fetch asynchronously after a drag has concluded. Think of Flickr as an example. IMBObjectsPromise provided an abstraction layer that made Flicker and Finder or iTunes look exaclty the same from an API point of view. Since iMedia 3 has been completely redesigned to be asynchronous via XPC services anyway, this additional layer of abstraction was not longer necessary!

That's why we simply got rid of the class. BTW, drag & drop related code in the framework is reduced to about 25% now. The new APIs work a lot better and are much easier to understand!

Oh I agree that the modern pasteboard API is much more pleasant! (if a little confusing at first).

I guess the big problem I have with drag and drop right now is the async nature of the Flickr parser in particular. From a naive client’s point of view, the only usable pasteboard type available to it is a local URL/path. iMedia has to create the file at that location on-demand. And then tidy it up at some point. Presently, the Flickr parser relies until on the OS rebooting to perform that cleanup.

There may well be other parsers in a similar situation, but none come to mind.

It seems to me that either file promises, or promising image data, fall better inline with how the pasteboard operates on OS X. Drag/paste recipients get some of the async/lazy benefit our custom system offers. Although with the caveats:

- file promises tend to be synchronously fulfilled in practice, but there is no requirement to do so

- when asynchronously fulfilled, file promises have no means to notify clients when finished

- promised image data must be provided synchronously

Some effects can be minimised by assuming at the start of a drag or copy operation that the resulting data *will* eventually be used. Therefore loading the image can begin immediately, with a good chance it will be finished by the time the drop or paste actually occurs. This should lower the waiting time in target apps.

Do we do this for drags at all in iMedia 3? Or do we still wait until the system asks a promise be fulfilled? (i.e. upon the paste or drop)