Re: Q about your DnD changes

[Fred Kiefer]

Willem Rein Oudshoorn wrote:
> 
> I have a few questions about your changes to the XGDragView.
> 
> 1 - Why did you change the lines like
>         [XGContext ...]
>     to
>         [isa ...] ?
> 
>     I am just curious.  It is not a construct I use normally.
>     Is it for performance reasons?

Yes, this was just a performance improvement I did as I changed some
other code in that file. I did the same change a while ago when I had to
touch the XGContextWindow.m file and I will do the same if I ever change
things in XGContextEvent.m.
The construct "isa" is a faster way to refer to the back pointer to the
class. Another way to do it is [self class]. The reason I did this small
change is that referring to a class via its name is one of the single
most expensive operations in the Objective-C language (or at least in
the gcc implementation of it). So as long as the compiler wont optimize
this, we have to do it ourselves.

> 2 - I noticed that you check now before dropping
>     if the targetMask is not equal to NSDragOperationNone.
> 
>     Maybe it is better if we check:
> 
>     (targetMask & dragMask & operationMask) != 0
> 
>     [that is, we only initiate a drop when:
>         source and target and key modifiers
>      agree that a drag is possible.]
> 

You are right here. I only thought about well behaving targets that
would return a valid mask, but they don't have to and so we need to take
caution here.

> 3 - I read a comment that you wanted to handle
>     the status update for a local drag directly
>     and bypass the X-server.   The reason stated was
>     that otherwise in the converions information would get lost.
> 
>     I agree that in the current conversion information gets lost.
>     However by using the xdnd protocol better.  That is,
>     when the operation(s) do not map directly to predefined
>     xdnd types we can use the XdndAsk action.
>     This will allow us to use the XdndActionList to
>     transfer all the data we want.
>     This has two advantages:
> 
>      - No seperate code for local / external
>      - Better conformance to the Xdnd protocol.

I already did that change in my working copy and I still see nothing
wrong with it. I would be glad, if you will implement a better handling
of the different drag mask latter on. Currently the benefit of a correct
implementation inside of GNUstep out weights the costs of the five lines
I had to add for it.

> P.S.: I am still thinking about the question you raised about
>       the Drag pasteboard.  I am not sure if what you want
>       is the right way.  But I need to understand X selections
>       better before passing a judgement.

To answer this I will add some lines from your other mail, where you
made that questions more explicit. But first I must admit that I am
myself not that sure if this will be the best solution for DnD support
in GNUstep. Still it will definitely be an improvement over the current
code. And any further improvements are welcome.

> Fred Kiefer wrote:
> 
> > The subclass XDragPbOwner tries to do similar things with the drag
> > pasteboard, but it has no chance to know what data will be provided
> > nor which window will make this data available. The xdnd protocol
> > will only signal which types are available when entering a window.
> 
> Why is this a problem?  It seems that it should be possible to write a
> pasteboard, just for drag and drop that will act as an frontend for
> the XdndSelection of xdnd.  The missing type info does not seem a
> problem.  If we are dragging from a non GNUstep application the first
> thing that will happen is a XdndEnter.  At that moment we know the
> types.  So from then on everything is fine.
> 
> For GNUstep --> GNUstep transfers.  You can always store additional
> information.   For GNUstep --> X , well we have to provide
> the XdndSelection data anyway.  

Here part of the confusion comes from my inability to express myself
clearly in written language. To try it again:
The main problem simply is, who will be owning the drag pasteboard in
GNUstep for an external drag operation.

This might either be a pasteboard handler in the xpbs.m file
(XDragPbOwner), that notices that someone else did take over the
pasteboard. But at that time a dragging application does not have to
provide information about the available types. They only have to do this
later on, when the cursor enters a window that accepts dragging. (And
any declaration of types here would take over the pasteboard!) 
So here we would need a way to acquire the pasteboard, but to declare
only later on which data types will be available. Or we will only
interact with applications that first declare their drag types and after
this take over the X drag selection.

The other solution is that the drag info will provide the data from X
for the drag pasteboard. As it will be notified of a drag enter it is in
the right place to do so. But currently it is totally missing all the
code to do the selection transfer, which is (in some rudimentary form)
already there in the XPbOwner class. And this code is rather more
complicate than I first thought.

To add to this difficulties xdnd expects to have a direct communication
between two windows, the one providing the data and the one that may
accept it. We currently have four of them, adding the window in xpbs
that does the data transfer and the one from XGDragView. Most xdnd
applications wont get confused by this, but some might just refuse to
send data to a window, they don't know about. (We also cannot use the
proxy addition from xdnd release 4, as currently the interaction window
is in another application, the pasteboard server)
As you see some of the difficulties come from the xdnd specification
that is not as specific enough, so we don't know which behaviour will be
shown by other applications. And some come from our separation of the
DnD code into two applications.

I hope this explains everything a bit better. This is still no prove
that my new architecture would solve this problems. And as I spend to
much time to write this mail, I wont have time in this year to write the
program, so this leaves some time to discuss the issue once again. But
don't expect me to answer before mid of January. I will be on holidays
for the next two weeks and after that move over to England. This wont
leave any time for GNUstep.

Fred