From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: Drag and drop patch for X, please review. Date: Tue, 20 Jan 2004 22:27:58 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <849323AA-4B8F-11D8-A2D5-00039363E640@swipnet.se> References: <200401171729.i0HHT1wq016912@stubby.bodenonline.com> <20040118004009.GA24635@fencepost> <2C5AAB61-49F7-11D8-A763-00039363E640@swipnet.se> <74293710-4B62-11D8-89AF-00039363E640@swipnet.se> <39277C06-4B8A-11D8-AF87-00039363E640@swipnet.se> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1074641180 32745 80.91.224.253 (20 Jan 2004 23:26:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 20 Jan 2004 23:26:20 +0000 (UTC) Cc: emacs-devel@gnu.org, Miles Bader Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Jan 21 00:26:03 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Aj5Fz-00064S-00 for ; Wed, 21 Jan 2004 00:26:03 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1Aj5Fz-00069P-00 for ; Wed, 21 Jan 2004 00:26:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Aj4r9-0005ow-2a for emacs-devel@quimby.gnus.org; Tue, 20 Jan 2004 18:00:23 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Aj3kq-0005Jk-CE for emacs-devel@gnu.org; Tue, 20 Jan 2004 16:49:48 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Aj3kE-00059N-8d for emacs-devel@gnu.org; Tue, 20 Jan 2004 16:49:42 -0500 Original-Received: from [213.115.192.53] (helo=mail2.norrnet.net) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Aj3QI-0002gr-44; Tue, 20 Jan 2004 16:28:34 -0500 Original-Received: from stubby.bodenonline.com (stubby.bodenonline.com [193.201.16.94]) by mail2.norrnet.net (BorderWare MXtreme Mail Firewall) with ESMTP id 3D41DEED0F; Tue, 20 Jan 2004 22:25:25 +0100 (CET) Original-Received: from accessno42.bodenonline.com (accessno42.bodenonline.com [193.201.16.44]) by stubby.bodenonline.com (8.12.1/8.12.1) with ESMTP id i0KMKj7L008142; Tue, 20 Jan 2004 23:20:48 +0100 In-Reply-To: Original-To: Stefan Monnier X-Mailer: Apple Mail (2.609) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:19368 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19368 2004-01-20 kl. 22.12 skrev Stefan Monnier: >> Later when the mouse moves, the source sends XdndPosition messages, >> which among other things, contains the suggested action the source >> wants to do. The target replies with XdndStatus messages. The answer >> contains among other things, the action the target wants to perform >> (copy, >> move, private) and if it is acceptable to drop where the mouse is >> currently. > > Why does the source app send XdndPosition (rather than the target app > keeping track of mouse movements) ? Is suh an XdndPosition message > sent > every time the mouse moves within the target's window ? > What is the purpose of the XdndStatus message? I.e. how does the > source > use this information? I can see its usefulness once the drop actually > takes place, but during dragging I can't think of anything useful the > source could do with it. 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. Also if for example, a press on a shift key while dragging means move, and unshifted means copy, the source must inform the target that the action has changed. There is an optimization where the target in the XdndStatus message tells the source not to send XdndPosition when the mouse is inside a given rectangle. But the target must be prepared to accept XdndPositions anyway, the source is free to ignore the given rectangle (which indeed GTK does, Qt honors the rectangle). 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. 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. > >> So if the mouse travels from the menu bar, to the tool bar, to a read >> only buffer, to an ordinary buffer, and then to a dired buffer, and >> then >> we do the drop, Emacs must send XdndStatus messages back to the source >> with different actions in them. > > What happens if it just always sends some dummy XdndStatus message > instead? > What happens if it waits for the button-release before sending any > XdndStatus? 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 correctly. The target does not get any button release info, the mouse is grabbed by the source. The only indication the target gets about button release is the XdndDrop message, or an XdndLeave message if the drop was rejected by the last XdndStatus message. > >>> Obviously, if there's no binding for the drop event at the drop >>> location, >>> you should not accept the drop action. So view-mode could explicily >>> unbind the drop event, for example. > >> As can be seen above, we need to know this before the drop occurs. > > That's OK: we can lookup keymaps during the drag to figure out whether > dnd-drop is bound at the location under the mouse. That is true. Jan D.