[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Drag and drop patch for X, please review.

From: Jan D.
Subject: Re: Drag and drop patch for X, please review.
Date: Tue, 20 Jan 2004 23:28:30 +0100

To simplify for the target.  It may also be that there are several
pointer devices (indeed, on my laptop, I can use three mice at the same
time), and the target can not know which one is used.

I've seen and used multiple mice, but they always all applied to the one and only on-screen-cursor. So from an Xclient point of view, there's really only
one input device (which is composed of several mice).

It is not a strict requirement.  There can be multiple pointer devices.
In some accessibility functions you can simulate the mouse actions
with arrow keys.

XdndStatus tells the source if the drop is accepted, and the above mentioned
rectangle.  The source uses the accept/reject status to change the
icon that is being dragged so the user can visually see if drop is
accepted or rejected where the mouse is now.

Talk about stupid design: the user is obviously looking at the target while dragging, so any indication should happen there rather than at the source.

The icon I am talking about is the one the user drags, i.e. it is
where the pointer is.
It is actually recommended that the target does some visible indication
also, such as highlight the window border. Most apps doesn't do that. The
target can not have control over any visible indication at the pointer,
first the source has grabbed the pointer, secondly the drop starts
at the source, so what the dragged icon looks like is not known by
the target.

It would also eliminate this need for constant XdndStatus communication.
I'm obviously missing something.

The status messages are mostly a way for the target to change the state,
i.e. change reject/accept and/or change the rectangle where it does not
want more position messages.

Also, if the mouse button is released and the last XdndStatus said reject, the source usually does a bit of animation so the dragged icon is "snapped
back" to where the drag started.

But that could be triggered by a XdndReject response to XdndDrop, so it
does not justify XdndStatus.

In the XdndFinished message the target tells the source if the drop
was successful or not.  But the XdndStatus messages are needed anyway
to inform the source if it should send a XdndDrop at all.  The
XdndFinished is only to be sent after a XdndDrop message.

If we don't send any XdndStatus, the source will conclude that the
target can not accept any drop whatsoever, and never send the XdndDrop
message.  A dummy is no good, we at least needs to set accept/reject

Seems like `accept' would be a good dummy, if needed.

Then we are back to saying accept and then later perhaps signal
an error.  I do not like that.  If we know we are going to raise an
error, we should not accept the drop in the first place.

        Jan D.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]