unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Third <alan@idiocy.org>
To: "Paul Magwene, Ph.D." <paul.magwene@duke.edu>
Cc: "43470-done@debbugs.gnu.org" <43470-done@debbugs.gnu.org>,
	"Daniel Martàn" <mardani29@yahoo.es>
Subject: bug#43470: 27.1; Drag and Drop not working properly in 27.1 on OSX
Date: Sat, 19 Sep 2020 15:08:17 +0100	[thread overview]
Message-ID: <20200919140817.GB28875@breton.holly.idiocy.org> (raw)
In-Reply-To: <C82E3069-899F-42DF-A966-775144058F8C@duke.edu>

On Fri, Sep 18, 2020 at 11:22:46PM +0000, Paul Magwene, Ph.D. wrote:
> 
> My testing suggests that there's still source application specific behavior.
> 
> * Simple drag of images works when Safari or Chrome is the web browser.
> 
> * No combination of Option, Command, or Control seems to work in Firefox; the drag behavior always produces a URL.

That's how Apple designed it, what we wanted to avoid was where the
source application defined which modifiers Emacs saw in use as that
just turned into a nightmare of random behaviour.

Probably what's happening is that Firefox is setting some drag
operations that don't include NSDragOperationCopy, which is the one we
chose to always try opening the text as a URL.

It would be interesting to know what it's setting. You could try
adding something like

    NSLog ("%lx", op);

into performDragOperation in nsterm.m and then we can compare it to
the constants listed here:

    https://developer.apple.com/documentation/appkit/nsdragoperation?language=objc

> So I guess the patch partially fixes the regression. Given the state
> of the OS X api I'm not sure what the best way forward is. I'd try
> and jump in to contribute but I unfortunately have zero experience
> working with Objective C or programming against Apple's APIs

The ns-drag-n-drop function is customisable, so if you wanted to
ALWAYS force it to try and open ANY text as a URL you could do
something like

(defun ns-drag-n-drop (event)
  "Edit the files listed in the drag-n-drop EVENT.
Switch to a buffer editing the last file dropped."
  (interactive "e")
  (let* ((window (posn-window (event-start event)))
         (arg (car (cdr (cdr event))))
         (type (car arg))
         (objects (cdr (cdr arg))))
    (set-frame-selected-window nil window)
    (raise-frame)
    (setq window (selected-window))
    (princ operations)
    (dolist (data objects)
      (dnd-handle-one-url window 'private (if (eq type 'file)
                                              (concat "file:" data)
                                            data)))))

It's quite possible we should have more logic in ns-drag-n-drop to
work out what to do given the data type and available dragging
options.

BTW, Apple's documentation seems to be inconsistent. One page[1] has
this table:

    | Modifier Key       | Dragging Operation  |
    |--------------------+---------------------|
    | Option             | NSDragOperationCopy | 
    | Command            | NSDragOperationMove | 
    | Option and Command | NSDragOperationLink | 

and another[2] has this:

    | Modifier Key | Dragging Operation     |
    |--------------+------------------------|
    | Control      | NSDragOperationLink    |
    | Option       | NSDragOperationCopy    |
    | Command      | NSDragOperationGeneric |

The latter seems to be the correct one.

[1] https://developer.apple.com/documentation/appkit/nsdragginginfo/1415966-draggingsourceoperationmask?language=objc
[2] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/DragandDrop/Concepts/dragsource.html#//apple_ref/doc/uid/20000976-104936
-- 
Alan Third





      parent reply	other threads:[~2020-09-19 14:08 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-17 13:27 bug#43470: 27.1; Drag and Drop not working properly in 27.1 on OSX Paul Magwene, Ph.D.
2020-09-17 17:46 ` Alan Third
2020-09-17 18:12   ` Unknown
2020-09-17 19:46     ` Alan Third
2020-09-18 12:00       ` Unknown
2020-09-18 12:54         ` Alan Third
2020-09-18 18:34           ` Unknown
2020-09-18 19:11             ` Alan Third
2020-09-18 21:27               ` Paul Magwene
2020-09-18 22:15                 ` Alan Third
2020-09-18 23:22                   ` Paul Magwene, Ph.D.
2020-09-19 11:02                     ` Unknown
2020-09-19 12:45                     ` Unknown
2020-09-22 12:24                       ` Alan Third
2020-09-26 11:39                         ` Unknown
2020-09-27  9:59                           ` Alan Third
2020-09-27 22:22                             ` Unknown
2020-10-03 14:43                               ` Alan Third
2020-09-26 11:39                         ` Unknown
2020-09-19 14:08                     ` Alan Third [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200919140817.GB28875@breton.holly.idiocy.org \
    --to=alan@idiocy.org \
    --cc=43470-done@debbugs.gnu.org \
    --cc=mardani29@yahoo.es \
    --cc=paul.magwene@duke.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).