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 17:05:23 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <74293710-4B62-11D8-89AF-00039363E640@swipnet.se> References: <200401171729.i0HHT1wq016912@stubby.bodenonline.com> <20040118004009.GA24635@fencepost> <2C5AAB61-49F7-11D8-A763-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 1074615971 9589 80.91.224.253 (20 Jan 2004 16:26:11 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 20 Jan 2004 16:26:11 +0000 (UTC) Cc: Miles Bader , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Jan 20 17:25:46 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 1AiyhF-0005s1-00 for ; Tue, 20 Jan 2004 17:25:45 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AiyhF-00065G-00 for ; Tue, 20 Jan 2004 17:25:45 +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 1AiydQ-00020M-TJ for emacs-devel@quimby.gnus.org; Tue, 20 Jan 2004 11:21:48 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AiyQb-0005eg-TW for emacs-devel@gnu.org; Tue, 20 Jan 2004 11:08:33 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AiyOc-0004wU-H1 for emacs-devel@gnu.org; Tue, 20 Jan 2004 11:07:02 -0500 Original-Received: from [213.115.192.53] (helo=mail2.norrnet.net) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AiyOb-0004vu-Ji; Tue, 20 Jan 2004 11:06:29 -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 C8C7BAEA19; Tue, 20 Jan 2004 17:03:24 +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 i0KGwk7L002219; Tue, 20 Jan 2004 17:58:47 +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:19351 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19351 >> Also, I don't think it is worth doing, it is too complex for very >> little >> user benefit. > > Looking at it from my armchair, it doesn't look that complex ;-) > You basically need to do a bunch of keymap lookups rather than a bunch > of > alist lookups. And you need to create an event, which might indeed be > more > work, I don't know. The problem is more figuring out where the mouse is, i.e. menu bar, scroll bar or tool bar. Right now, I just see if the position corresponds to a window and if not, it is somewhere in those three, the details does not matter. It may not be a complex thing, but all these events must interract so that if a drop starts with [menu-bar dnd], then enters a window, i.e. [dnd], and then exits via a [scroll-bar dnd], the global data needed for the drop must be synchronized so that it is correctly updated. > >> Better then to accept the drop and put it in the kill ring >> if we can't insert it into a buffer. > > That's up to the command bound to the event. All that I wanted to > point out > by my original remark is that it's OK to accept the drop even if the > buffer > is read-only: we can then signal an error (and/or do whatever else we > feel > like). Or in more general terms, it's OK to accept a drop before > knowing > whether the action can be carried through. All we need to figure out > really > is *which* type of drop to use. I don't feel comfortable with accepting a drop and then signal an error. I think this goes a bit against the "spirit" of drag and drop in a small way. The reason why the source of the drop gives a list of types and a suggested action (copy, move etc.) at the start of the drop is just so that the target can decide if to accept the drop or not. Also, many programs (all GTK for example) have a visual indicator to show if the drop can be made or not where the mouse is. If Emacs just accepts everything and then signals an error would be bad user interface IMHO. Better then to show the user that he can't drop here, or that he can, but the results have to be manually extracted from the kill ring. Jan D.