Re: Custom drag image for NSTableView selections
Re: Custom drag image for NSTableView selections
- Subject: Re: Custom drag image for NSTableView selections
- From: email@hidden
- Date: Fri, 12 Jul 2013 13:29:20 +0900
On 2013/07/12, at 10:49, Graham Cox <email@hidden> wrote:
>
> On 12/07/2013, at 10:35 AM, email@hidden wrote:
>
>> However, based on the way I have simply put the row selection indexes NSIndexSet into NSData and into the pasteboard, the API as I see it at the moment (using NSDraggingSession property draggingFormation ) may not work for me without some additional work.
>>
>> I wasn't really wanting to put the represented objects of my rows on to the pasteboard, since NSView and NSTableView do a lot of the dragging API work already, it may have to be a feature I handle later, it looks like a lot of work for now, and the API seems spread out amongst a lot of different classes I am not familiar with… :(
>
>
> Is the drag expected to work between different apps or simply within your own app?
Both.
Internal for reordering rows for now.
But will be adding drag to move and drag to copy between collections, as well as drag to external for copying a text or image representation.
>
> If the latter, there is no reason to put anything on the pasteboard other than enough dummy data to identify the drag (usually your private drag type and an empty string are enough). When you start the drag, put the real data somewhere accessible, such as a class method. When you receive the drag and identify it as this private type, use the class method to get the data. That data can be the original index set for example (though as far as I can see there's nothing to stop you putting the index set on the pasteboard directly, not sure why you need to convert to NSData).
Hadn't thought of it that way. Examples of drag to reorder that I saw all used NSData IIRC. ...
>
> The point is that the drag APIs standardise the visual side of the process, but do not force you to use the data side of the process unless the objective is to pass data between apps. Particularly for table reordering or dragging in and out of tables, it's often much easier to bypass the data side of the drag manager. Putting your actual objects on the pasteboard is a waste of time, since they're only going to be converted back again in a different place within the same app.
Good perspective!
This makes it really like the drag op destination is a manually initiated notification in my mind.
I will give this a try as it promises to clean up some unnecessary code.
But to support the other kinds of drag ops, I may need to go with a heavier weight pasteboard entry? ( since there's no way to preemptively know the destination)
I still want to control the drag image in any drag op and have a bit of learning and experimenting to do in that space.
But I will start with one. ;)
Last for polish I need to figure out the animation of row reordering when drag is internal. But that's not the highest priority at the moment.
>
> --Graham
>
_______________________________________________
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