Re: X Dragging interaction

[Richard Frith-Macdonald]

On Friday, December 21, 2001, at 12:32 AM, Fred Kiefer wrote:

> To get out of this dilemma I would recommend that we drop this extension
> of the pasteboard for dragging and implement all of the X drag code in
> the XGDragView class. As this class has already a window, this would be
> used to export data for dragging that started in the GNUstep application
> to non GNUstep applications (GNUstep applications would still get there
> data from the Drag pasteboard). And when a drag from the outside will
> enter a GNUstep application the XGDragView will be notified and take
> over the drag pasteboard (which will be freed again, if the cursor moves
> outside the window again) and declare all the types that are available
> for DnD. When a drop happens inside of a GNUstep window, the XGDragView
> will ask via the xdnd protocol for that data and add it to the
> pasteboard.
>
> This implementation lacks some elegance, as the drag pasteboard is no
> longer managed by a shared background process and different GNUstep
> applications running at the same time, may have to declare the same
> types to the drag pasteboard when the drag cursor moves over them. Still
> it is the only working solution I see.

Looks feasible ... I first thought that not using the drag pasteboard and
doing everything in the view code would be a problem - but checking the
documentation, it seems that a well-behaved drag recipient should send a
'-draggingPasteboard' message to the 'sender' supplied as the argument to
the '-performDragOperation:'  and of course this method could set up a
pasteboard from X data and return the pasteboard object without talking
to the pasteboard server.
I guess, If we wanted to be sure that the drag pasteboard actually 
contained
the drag data, we could send the data to the pasteboard server before 
calling
the -performDragOperation: method on the destination anyway.