From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Drag and drop patch for X, please review. Date: Wed, 21 Jan 2004 16:08:59 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: 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> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1074719955 22051 80.91.224.253 (21 Jan 2004 21:19:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 21 Jan 2004 21:19:15 +0000 (UTC) Cc: miles@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Jan 21 22:19:06 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 1AjPkg-0002QT-00 for ; Wed, 21 Jan 2004 22:19:06 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AjPkg-0007jN-00 for ; Wed, 21 Jan 2004 22:19:06 +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 1AjPgg-0002Ro-2A for emacs-devel@quimby.gnus.org; Wed, 21 Jan 2004 16:14:58 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AjPdd-0001N2-Ox for emacs-devel@gnu.org; Wed, 21 Jan 2004 16:11:49 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AjPcy-00015W-G1 for emacs-devel@gnu.org; Wed, 21 Jan 2004 16:11:39 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AjPcx-00014m-CZ for emacs-devel@gnu.org; Wed, 21 Jan 2004 16:11:07 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.24) id 1AjPat-0003Cs-Gz; Wed, 21 Jan 2004 16:08:59 -0500 Original-To: "Jan D." In-reply-to: <39277C06-4B8A-11D8-AF87-00039363E640@swipnet.se> (jan.h.d@swipnet.se) 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:19415 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19415 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. Possibly we want to do private on the menu bar and tool bar, not accept the drop in the read only buffer, then send private again when entering the ordinary buffer, and then send the action the target suggests (move, copy) when entering the dired buffer so that dired acts like a file manager. I think it is better not to try to say yes and no in different Emacs buffers. We should treat all of the buffer text areas in a uniform way as regards accepting drops there. However, the menu bars could be treated differently, since the C code can tell whether the pointer is in a menu bar. Likewise, maybe Emacs could always reject drops in scroll bars, or in the echo area when the minibuffer is inactive (or maybe always in the echo area). The C code can tell if a window is a minibuffer window and whether it is active. Mode lines also would have to be treated uniformly, I guess. Is there a useful meaning for a drop in the mode line? Different buffers can still handle the same kind of drop in different ways, based on local key bindings. There's no need to look thus up except at the end, in response to the event. If we want dropping a file into the menu bar to open the file, then I suggest it open the file using find-file-other-window. While no method is always best, that's the way users most often prefer.