Re: Have there been recent changes in DnD?

[Fred Kiefer]

Andreas Schik wrote:
> On 2008-01-16 11:49:32 +0100 Andreas Schik <andreas.schik@web.de>
> wrote:
> 
>> On 2008-01-14 13:10:17 +0100 Fred Kiefer <fredkiefer@gmx.de> wrote:
>>
>>> Andreas Schik wrote:
>>>> On 2008-01-10 21:46:38 +0100 Fred Kiefer <fredkiefer@gmx.de> wrote:
>>>>
>>>>> Andreas Schik wrote:
>>>>>> since I 'upgraded' to yesterdays SVN og GNUstep I do have problems
>>>>>> with DnD in GNUMail. Have there been any changes in the underlying
>>>>>> mechanisms making it necessary to change applications?
>>>>>>
>>>>> The basic mechanism hasn't changed since April last year. What has
>>>>> changed a bit was the implementation for NSTableVie and NSTextView.
>>>>> Are
>>>>> you using subclasses of these?
>>>> It looks like GNUMail is using a subclass of NSTableView in the mail
>>>> window. This table is the source of the operation. What I found out so
>>>> far is that the target of the operation (outline view) in the method -
>>>> outlineView:validateDrop:proposedItem:proposedChildIndex: receives
>>>> NSDragOperationNone in the NSDraggingInfo object ([info
>>>> draggingSourceOperationMask]), no matter which modifier I press down.
>>>>
>>>
>>> There has been one important change for dragging in NSTableView, which
>>> may affect that code in some way. Now there are different drag mask
>>> settings for local and non-local dragging. The later by default is set
>>> to NSDragOperationNone. This behaviour matches, as far as I know, what
>>> Apple is doing. But why would the drag view see this as a non-local drag
>>> operation?
>>>
>>> What you should do is debug into GSDragView (and it's subclass XX) to
>>> see, how the value for draggingSourceOperationMask is build up from
>>> dragMask (coming from the drag source) and operationMask (coming from
>>> the modifier keys). One of these two (most likely dragmask) must be
>>> wrong.
>> Well, it is not a GNUMail problem, but a combination of GNUstep and
>> Camaelon.
>> Camaelon introduces a category for NSTableView that does not call the
>> (assumedly new) selector -_initDefaults: Hence, the local dragging
>> mask is 0. Fixing this remedies part of the problem. What remains is a
>> quite strange behaviour:
>> If I overlap the mailbox window and the mail window of GNUMail the
>> operation works. As soon as there is a gap between the windows, i.e.
>> the drag operation touches an external application, the operation
>> again fails. It looks like GSDragView does not recognize that it must
>> switch back from non-local to local operation. It did not debug this,
>> though, and probabyl won't have time today to do so. But this might
>> anyway help you to track it down.
> This did let me sleep :-)
> Find a patch attached to this mail that fixes GSDragView. It finally
> came down to a missing ! operator.
> 

Thank you for solving this! I just submitted your change to SVN.

Fred