Re: Determining an inter-application drag source
Re: Determining an inter-application drag source
- Subject: Re: Determining an inter-application drag source
- From: "Jeffrey J. Early" <email@hidden>
- Date: Fri, 26 Mar 2010 10:43:34 -0400
Gotcha -- sorry if I read into that a bit much.
I haven't complained this as a missing feature here at all yet -- I was actually still under the impression that there was a mechanism to determine the drag source that I didn't know about. As the consensus appears to be that there isn't, I will file a bug report.
Jeffrey
On Mar 26, 2010, at 10:28 AM, Steve Christensen wrote:
> I wouldn't say that there has been any argument over whether or not knowing the drag source is a good thing; we were simply asking why you needed to know. You could have just as easily made a bad assumption about something else and were trying to fix it in the drag.
>
> And if you would like to see a new OS or application feature, file a bug at <http://bugreport.apple.com/>. Just grousing about it here will not effect change within Apple.
>
>
> On Mar 26, 2010, at 7:00 AM, Jeffrey J. Early wrote:
>
>> I apparently didn't hit reply-all on my response to Steve.
>>
>> I wrote:
>> When a user drags a photo from iPhoto to my application I need to be able to update iPhoto's database (via ScriptingBridge) with changes that are made while in my program. Other programs require different bits of "extra work" to at least provide the user some extra information about how things will or won't be updated. iPhoto fortunately provides some extra information in the pasteboard that distinguish itself, but Lightroom does not.
>>
>> In my case, because I know the possible sources are (mostly) limited to a few programs, I have some other work arounds I might try. For example, testing to see if the applications are open and then querying their databases directly to see if they manage that particular file. None of this kind of thing failsafe, however.
>>
>> But let me add:
>> I'm not even sure why the apparent argument is that it theoretically it shouldn't matter. Why is the "pure" abstraction that we don't need to know the source of the information? We get that information when the drag is within our own application -- why should inter-application be any different. Sure in most cases that's probably fine, but aren't exceptions the rule the programming?
>>
>> In my case I suppose that one could argue it's the failure of these digital asset managers (iPhoto, Lightroom, Aperture) to provide robust hooks to their assets. Maybe they should be aware that if they're handing a path to a file they're managing, that they might need to do some updates later on. But, regardless of whether that should be the case, it isn't.
>>
>> Jeffrey
>>
>> On Mar 26, 2010, at 7:59 AM, Matt Gough wrote:
>>
>>> A fragile way would be to see what other drag types are being put on the pasteboard. I imagine Finder has some esoteric old types for backwards compatibility and I would guess that Aperture has some image types that the Finder wouldn't normally use (except maybe for picture clippings)
>>>
>>> But as Steve said, why should it matter?
>>>
>>> Matt Gough
>>>
>>> On 25 Mar 2010, at 23:22:54, Steve Christensen wrote:
>>>
>>>> I'm curious why you need to know where the drag originated since it generally shouldn't matter. Do you have to do some extra work in one case? And what happens if you see a drag from another application?
>>>>
>>>>
>>>> On Mar 25, 2010, at 7:55 AM, Jeffrey J. Early wrote:
>>>>
>>>>> Is there any way to determine the source of a drag operation outside your own application? For example, if I'm set to receive NSFilenamesPboardType, then I'd like to distinguish between the Finder and Aperture as drag sources.
>>>>>
>>>>> I had thought I'd seen a solution to this at one point, but can't seem to find anything. The draggingSource in <NSDraggingInfo> is set to nil when the source is an external application. The pasteboard doesn't seem to guarantee any that information, although some sources will occasionally have unique pasteboard types that might distinguish them, but only as an exception.
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden