bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

Robert Weiner-2
On Wed, Oct 11, 2017 at 1:16 PM, Robert Weiner <[hidden email]> wrote:

​Martin wrote:​
Take the position of the event-end (if it's a frame) and translate it
into absolute screen coordinates (the Elisp manual should give you
enough clues to do that).  Or, try ‘mouse-absolute-pixel-position’ - it
should give you the screen position of the mouse at that time so you can
ignore the event completely.

Then walk all your windows and compare that position with whatever
‘window-absolute-pixel-edges’ returns for that window.  If you have two
or more positives, run ‘frame-list-z-order’ and compare the result
against those windows' frames.  No hands, IMHO.
​​
​​
 
​  Eli wrote:
    ​​
Why cannot you compute the frame at button release using the a
​​
lgorithm

         proposed by Martin, given the mouse position at button release?
 
 
​​
I w
​​
rote:
  ​
​​
frame-list-z-order is Emacs 26 only; I need something that works with older versions.​
​​
​​
I'll see if I can make this work under Emacs 26 and then we can contemplate a solution that would apply to earlier versions.
​​
Thanks for the reminder.  It does still seem to me that there should be a function that takes a mouse position and returns
​​
the top-most Emacs window that the position is in or nil.  I'll work on it.
​​
​​​And now there is such a function.  It was easier than I expected thanks to Martin's pointers.  Now how can we make this work (replacing frame-list-z-order) for Emacs versions prior to 26?  -- Bob

(defun window-at-absolute-pixel-position (&optional position)
  "Return the top-most Emacs window at optional POSITION ((X . Y) in pixels) or mouse position.
If POSITION is not in a window, return nil.  Considers all windows on the the same terminal
display as the selected frame."
  (interactive)
  (setq position (or position (mouse-absolute-pixel-position)))
  (let* ((top-to-bottom-frames (frame-list-z-order))
(pos-x (car position))
(pos-y (cdr position))
edges left top right bottom
frame
in-frame
window)
    ;; First find top-most frame containing position.
    (while (and (not in-frame) top-to-bottom-frames)
      (setq frame (car top-to-bottom-frames)
    top-to-bottom-frames (cdr top-to-bottom-frames))
      ;; Check that in-frame is valid with frame-live-p since under macOS
      ;; when position is outside a frame, in-frame could be invalid and
      ;; frame-visible-p would trigger an error in that case.
      (when (and (frame-live-p frame) (frame-visible-p frame))
(setq edges (frame-edges frame)
      left   (nth 0 edges)
      top    (nth 1 edges)
      right  (nth 2 edges)
      bottom (nth 3 edges))
(when (and (>= pos-x left) (<= pos-x right)
   (>= pos-y top)  (<= pos-y bottom))
  (setq in-frame frame))))
    ;; If in-frame is found, find which of its windows contains
    ;; position and return that.  The window-at call below requires
    ;; character coordinates relative to in-frame, so compute them.
    (setq pos-x (/ (- pos-x left) (frame-char-width in-frame))
  pos-y (/ (- pos-y top) (frame-char-height in-frame))
  window (window-at pos-x pos-y in-frame))
    (if (called-interactively-p 'interactive)
  (message "%s at absolute pixel position %s"
   (or window "No Emacs window") position))
    window))
Reply | Threaded
Open this post in threaded view
|

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

Robert Weiner-2
I now have drags working across frames (after manipulating the drag button release event data to include the proper window and coordinates, though only in Lisp right now).  As shown in the last message, I also have a function that finds the proper Emacs window given some display coordinates.  The only remaining problem seems to be that none of this accounts for external application windows that may be obscuring an Emacs frame.

So if I have 2 frames, f1 and f2, and a Chrome web browser window that is atop f2, then if I drag from f1 into Chrome above f2, my drag release code reports that the release window is in f2 rather than nil, as it should be.  I am on macOS which uses click to focus, so Emacs still gets the release event since Chrome has not been selected with a click.

Is there any way to deal with external window z-order layering such that one can tell within Emacs whether the topmost OS-level window at an absolute mouse position is an Emacs frame or not?

Thanks,

Bob


On Wed, Oct 11, 2017 at 2:49 PM, Robert Weiner <[hidden email]> wrote:
On Wed, Oct 11, 2017 at 1:16 PM, Robert Weiner <[hidden email]> wrote:

​Martin wrote:​
Take the position of the event-end (if it's a frame) and translate it
into absolute screen coordinates (the Elisp manual should give you
enough clues to do that).  Or, try ‘mouse-absolute-pixel-position’ - it
should give you the screen position of the mouse at that time so you can
ignore the event completely.

Then walk all your windows and compare that position with whatever
‘window-absolute-pixel-edges’ returns for that window.  If you have two
or more positives, run ‘frame-list-z-order’ and compare the result
against those windows' frames.  No hands, IMHO.
​​
​​
 
​  Eli wrote:
    ​​
Why cannot you compute the frame at button release using the a
​​
lgorithm

         proposed by Martin, given the mouse position at button release?
 
 
​​
I w
​​
rote:
  ​
​​
frame-list-z-order is Emacs 26 only; I need something that works with older versions.​
​​
​​
I'll see if I can make this work under Emacs 26 and then we can contemplate a solution that would apply to earlier versions.
​​
Thanks for the reminder.  It does still seem to me that there should be a function that takes a mouse position and returns
​​
the top-most Emacs window that the position is in or nil.  I'll work on it.
​​
​​​And now there is such a function.  It was easier than I expected thanks to Martin's pointers.  Now how can we make this work (replacing frame-list-z-order) for Emacs versions prior to 26?  -- Bob

(defun window-at-absolute-pixel-position (&optional position)
  "Return the top-most Emacs window at optional POSITION ((X . Y) in pixels) or mouse position.
If POSITION is not in a window, return nil.  Considers all windows on the the same terminal
display as the selected frame."
  (interactive)
  (setq position (or position (mouse-absolute-pixel-position)))
  (let* ((top-to-bottom-frames (frame-list-z-order))
(pos-x (car position))
(pos-y (cdr position))
edges left top right bottom
frame
in-frame
window)
    ;; First find top-most frame containing position.
    (while (and (not in-frame) top-to-bottom-frames)
      (setq frame (car top-to-bottom-frames)
    top-to-bottom-frames (cdr top-to-bottom-frames))
      ;; Check that in-frame is valid with frame-live-p since under macOS
      ;; when position is outside a frame, in-frame could be invalid and
      ;; frame-visible-p would trigger an error in that case.
      (when (and (frame-live-p frame) (frame-visible-p frame))
(setq edges (frame-edges frame)
      left   (nth 0 edges)
      top    (nth 1 edges)
      right  (nth 2 edges)
      bottom (nth 3 edges))
(when (and (>= pos-x left) (<= pos-x right)
   (>= pos-y top)  (<= pos-y bottom))
  (setq in-frame frame))))
    ;; If in-frame is found, find which of its windows contains
    ;; position and return that.  The window-at call below requires
    ;; character coordinates relative to in-frame, so compute them.
    (setq pos-x (/ (- pos-x left) (frame-char-width in-frame))
  pos-y (/ (- pos-y top) (frame-char-height in-frame))
  window (window-at pos-x pos-y in-frame))
    (if (called-interactively-p 'interactive)
  (message "%s at absolute pixel position %s"
   (or window "No Emacs window") position))
    window))

Reply | Threaded
Open this post in threaded view
|

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

Robert Weiner-2
On Wed, Oct 11, 2017 at 9:35 PM, Robert Weiner <[hidden email]> wrote:

Is there any way to deal with external window z-order layering such that one can tell within Emacs whether the topmost OS-level window at an absolute mouse position is an Emacs frame or not?

​One idea is to expand frame-list-z-order with a 2nd optional argument of all-display-windows-flag which when non-nil would include all of the OS-level windows in the returned list.  Maybe a new object type or frame-variant is needed for this.  Then just add another function that returns the edge coordinates for such windows and we could account for them in any z-ordering computations.  What do you think?

Bob
Reply | Threaded
Open this post in threaded view
|

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

martin rudalics
In reply to this post by Robert Weiner-2
 > So if I have 2 frames, f1 and f2, and a Chrome web browser window that is
 > atop f2, then if I drag from f1 into Chrome above f2, my drag release code
 > reports that the release window is in f2 rather than nil, as it should be.
 > I am on macOS which uses click to focus, so Emacs still gets the release
 > event since Chrome has not been selected with a click.

I would call this a feature: f2 is probably the one meaningful target of
your operation at that screen position.

 > Is there any way to deal with external window z-order layering such that
 > one can tell within Emacs whether the topmost OS-level window at an
 > absolute mouse position is an Emacs frame or not?

Not really.  Compositing window managers on X no more allow to track the
visibility of windows reliably.  So while we can discern the visibility
of our own (window manager) windows based on what we store in their
asscociated frames' 'visible' slots, we can't do that for windows of
other applications.  And processing whatever else XGetWindowAttributes
returns for another application's window might not be trivial either.

It should be possible to do what you want on Windows (where the debugger
also notifies you when an Emacs frame is obscured) though.

martin



Reply | Threaded
Open this post in threaded view
|

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

Robert Weiner-2
On Thu, Oct 12, 2017 at 4:05 AM, martin rudalics <[hidden email]> wrote:
> So if I have 2 frames, f1 and f2, and a Chrome web browser window that is
> atop f2, then if I drag from f1 into Chrome above f2, my drag release code
> reports that the release window is in f2 rather than nil, as it should be.
> I am on macOS which uses click to focus, so Emacs still gets the release
> event since Chrome has not been selected with a click.

I would call this a feature: f2 is probably the one meaningful target of
your operation at that screen position.

​I think it is a feature that Emacs receives an event for this but a defect that it can't distinguish when f2 is atop an external window or not and thus whether the event was actually directed at f2 or not.

​​

​​

​​
> Is there any way to deal with external window z-order layering such that
​​
> one can tell within Emacs whether the topmost OS-level window at an
​​
> absolute mouse position is an Emacs frame or not?
​​

​​
Not really.  Compositing window managers on X no more allow to track the
​​
visibility of windows reliably.  So while we can discern the visibility
​​
of our own (window manager) windows based on what we store in their
​​
asscociated frames' 'visible' slots, we can't do that for windows of
​​
other applications.  And processing whatever else XGetWindowAttributes
​​
returns for another application's window might not be trivial either.

​Just FYI, I am using the macOS window manager, not X, though as you note, it is an issue there too.
The application-level window managers must have a z-ordering for all windows in order to be able to select and raise windows when they are behind others.  So you are saying that they don't publish this information in any useful way that Emacs can obtain, right?

Part of the issue is that the macOS window manager uses click-to-focus, so the release event of the drag does not switch focus to the application whose window the release falls upon.  However, in drag-n-drop operations, the window manager automatically switches focus to any compatible application that the mouse moves over (after a delay) so that the right application receives the drop (based on Z-order).

Mouse wheel events are also delivered to the topmost Z-order window without either raising the window or switching focus.

So the window manager always knows where it should deliver at least two kinds of events and maybe one of those types of events could be used to help Emacs know whether a release event was over one of its frames or over the window of an another application.


​​
It should be poss
​​
​​
ible to do what you want on Windows (where the debugger
​​
also notifies you
​​
when an Emacs frame is obscured) though.
​​
​​Well, one platform would be a good start.​  What would the pseudo-code look like to check whether or not an Emacs frame was uppermost at the point of mouse release?

Thanks,

Bob

Reply | Threaded
Open this post in threaded view
|

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

martin rudalics
 > ​I think it is a feature that Emacs receives an event for this but a defect
 > that it can't distinguish when f2 is atop an external window or not and
 > thus whether the event was actually directed at f2 or not.

‘mouse-drag-region’ is an Emacs internal function, so it's no defect.
If it were not internal, Emacs would have to be either able to poll the
other window's application as to whether it supports dropping an Emacs
internal string or convert that string to some appropriate coding that
other applications understand.  Neither of these has been done yet and
it will be non-trivial to do that for our various platforms.

 > ​Just FYI, I am using the macOS window manager, not X, though as you note,
 > it is an issue there too.
 > The application-level window managers must have a z-ordering for all
 > windows in order to be able to select and raise windows when they are
 > behind others.  So you are saying that they don't publish this information
 > in any useful way that Emacs can obtain, right?

All I can say is that when you nowadays try to obtain information on
whether a window is really visible under X, chances are that you don't
get it.  Querying the z-order will only tell you something like "window
Y cannot obscure window X because it's lower in the z-order".

 > Part of the issue is that the macOS window manager uses click-to-focus, so
 > the release event of the drag does not switch focus to the application
 > whose window the release falls upon.

As Stefan already mentioned earlier: With a drag operation usually no
focus shifting occurs anyway.

 > However, in drag-n-drop operations,
 > the window manager automatically switches focus to any compatible
 > application that the mouse moves over (after a delay) so that the right
 > application receives the drop (based on Z-order).

It's completely up to the window manager which polls the application(s)
whether they are ready to receive the object to drop.  Emacs is not
involved in that process.  It would be involved only to tell whether it
would accept such a string when it's the target of a drop.

 > Mouse wheel events are also delivered to the topmost Z-order window without
 > either raising the window or switching focus.

Mouse wheel events are completely different and highly window system
dependent.  Sometimes they get caught before Emacs sees them at all and
get transformed to scroll bar thumb drag events to the owner of the
scroll bar nearest to the mouse cursor at the time the wheel gets
scrolled.

 > So the window manager always knows where it should deliver

... it never "knows".  Some make better guesses and some make worse ...

 > What would the pseudo-code
 > look like to check whether or not an Emacs frame was uppermost at the point
 > of mouse release?

(1) ‘frame-list-z-order’ would have to be able to return all windows on
your system and (2) a function would be needed to get the attributes of
those windows.

martin




Reply | Threaded
Open this post in threaded view
|

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

Robert Weiner-2
Martin:

Thanks for commenting on this and sharing some of your extensive knowledge on window event handling and Emacs.

On Sat, Oct 14, 2017 at 4:35 AM, martin rudalics <[hidden email]> wrote:
> ​I think it is a feature that Emacs receives an event for this but a defect
> that it can't distinguish when f2 is atop an external window or not and
> thus whether the event was actually directed at f2 or not.

‘mouse-drag-region’ is an Emacs internal function, so it's no defect.
If it were not internal, Emacs would have to be either able to poll the
other window's application as to whether it supports dropping an Emacs
internal string or convert that string to some appropriate coding that
other applications understand.  Neither of these has been done yet and
it will be non-trivial to do that for our various platforms.

​Ok, that indicates that drag-and-drop from Emacs to external applications is unlikely but it still leaves the issue of recognizing whether a drag release event maps to an Emacs frame or not (when the frame is covered by an external app's window).  I already have code that recognizes this in Lisp; we should make it a primitive so the drag release code in Emacs could report more useful and accurate information in drag release events.

I guess you are saying that Emacs drag events must start and end within Emacs frames.  I think about it a bit differently.  Since the mouse can move in and out of Emacs frames and release events can occur (in logical Z-ordered OS window space) outside of Emacs, yet still register with Emacs (when the release occurs within the geometry of a frame but the frame is covered by another app's window), I think Emacs event handling should return different information when the release frame is not the topmost OS-level window at the point of release.  Then handler code could dispatch as necessary.

I already have Lisp code doing useful things with such information (presently, I have to adjust the drag release event information).  So I know it would be helpful to have this as default Emacs event reporting behavior.

​​

​​
> ​Just FYI, I am using the macOS window manager, not X, though as you note,
​​
> it is an issue there too.
​​
> The application-level window managers must have a z-ordering for all
​​
> windows in order to be able to select and raise windows when they are
​​
> behind others.  So you are saying that they don't publish this information
​​
> in any useful way that Emacs can obtain, right?
​​

​​
All I can say is that when you nowadays try to obtain information on
​​
whether a window is really visible under X, chances are that you don't
​​
g
​​
e
​​
t
​​
​​
i
​​
t
​​
.

​Each window has a 'visible' attribute.  Are you saying this is not accurate these days?​
​​​
  Querying the z-order will only tell you something like "window
​​
Y cannot obscure window X because it's lower in the z-order".

​We just want to know when given a screen position whether an Emacs frame is topmost at that position or not.​
​​​
​​

​​
> Part of the issue is that the macOS window manager uses click-to-focus, so
​​
> the release event of the drag does not switch focus to the application
​​
> whose window the release falls upon.
​​

​​
As Stefan already mentioned earlier: With a drag operation usually no
​​
focus shifting occurs anyway.

For the interactive things I am doing, I find that selecting the window of mouse release is always best but I agree it is not necessary in all instances.

​​

> However, in drag-n-drop operations,
​​
> the window manager automatically switches focus to any compatible
​​
> application that the mouse moves over (after a delay) so that the right
​​
> application receives the drop (based on Z-order).
​​

​​
It's completely up to the window manager which polls the application(s)
​​
whether they are ready to receive the object to drop.  Emacs is not
​​
involved in that process.  It would be involved only to tell whether it
​​
would accept such a string when it's the target of a drop.

​I understand that.  I was just noting that there is an example of a drag release event handler that selects the window of release as a standard part of its operation.

​​

​​

​​
> Mouse wheel events are also delivered to the topmost Z-order window without
​​
> either raising the window or switching focus.
​​

​​
Mouse wheel events are completely different and highly window system
​​
dependent.  Sometimes they get caught before Emacs sees them at all and
​​
get transformed to scroll bar thumb drag events to the owner of the
​​
scroll bar nearest to the mouse cursor at the time the wheel gets
​​
scrolled.

​Again, I was just providing context of what might be possible based on other event handling that occurs already in Emacs under macOS.​

​​

​​
> So the window manager always knows where it should deliver
​​

​​
... it never "knows".  Some make better guesses and some make worse ...

​On macOS the scroll wheel events seem to go to the right window 100% of the time from what I have seen.​

​​

​​
> What would the pseudo-code
​​
> look like to check whether or not an Emacs frame was uppermost at the point
​​
> of mouse release?
​​

​​
(1) ‘frame-list-z-order’ would have to be able to return all windows on
​​
your system

​Is it likely we could build a multi-platform primitive ​that would supply that information given what you have said?
​​​
​​
and (2) a function would be needed to get the attributes of
​​
those windows.

​2 seems straightforward.

Bob
​​

Reply | Threaded
Open this post in threaded view
|

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

Robert Weiner-2
On Sat, Oct 14, 2017 at 1:16 PM, Robert Weiner <[hidden email]> wrote:
it still leaves the issue of recognizing whether a drag release event maps to an Emacs frame or not (when the frame is covered by an external app's window).  I already have code that recognizes this in Lisp; we should make it a primitive so the drag release code in Emacs could report more useful and accurate information in drag release events.

​I misspoke.  I have code that detects when the release falls outside of the bounds of any Emacs frame.  However, when the release event is over an Emacs frame that is covered by another application's window, we don't yet have any information to tell us that, so I cannot detect it yet.  That is the problem we are discussing how to solve in a general way.

Bob
Reply | Threaded
Open this post in threaded view
|

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

Robert Weiner-2
On Sat, Oct 14, 2017 at 2:47 PM, Robert Weiner <[hidden email]> wrote:
On Sat, Oct 14, 2017 at 1:16 PM, Robert Weiner <[hidden email]> wrote:
it still leaves the issue of recognizing whether a drag release event maps to an Emacs frame or not (when the frame is covered by an external app's window).

​I have written a Python script that can be used to get this answer.  (It uses the Python-to-Objective-C bridge library that exposes the relevant Mac APIs to Python)​.  The script  takes two arguments, X and Y screen pixel coordinates, gets a list of all visible application windows in Z-order and then prints the application name of the first window that intersects the (X,Y) position, if any.  If that window is an Emacs frame, we have a match and otherwise, we don't.

This is a short script that really needs to be recoded into an Objective-C function that can be exposed to Emacs Lisp.  If anyone who is familiar with macOS Objective-C code would want to work with me on this, email me and I'll provide the Python code.  It is only about 28 lines.  -- Bob



Reply | Threaded
Open this post in threaded view
|

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

martin rudalics
In reply to this post by Robert Weiner-2
 > ​Ok, that indicates that drag-and-drop from Emacs to external applications
 > is unlikely but it still leaves the issue of recognizing whether a drag
 > release event maps to an Emacs frame or not (when the frame is covered by
 > an external app's window).  I already have code that recognizes this in
 > Lisp; we should make it a primitive so the drag release code in Emacs could
 > report more useful and accurate information in drag release events.

Even if the Emacs frame is covered by another application's frame,
nothing prevents us from having that covered Emacs frame accept the
drop.  We could even give frames a "no-accept-drops" parameter and this
way have a drop on such frames pass the drop through to yet another
frame below that does accept drops.

 > I guess you are saying that Emacs drag events must start and end within
 > Emacs frames.  I think about it a bit differently.  Since the mouse can
 > move in and out of Emacs frames and release events can occur (in logical
 > Z-ordered OS window space) outside of Emacs, yet still register with Emacs
 > (when the release occurs within the geometry of a frame but the frame is
 > covered by another app's window), I think Emacs event handling should
 > return different information when the release frame is not the topmost
 > OS-level window at the point of release.  Then handler code could dispatch
 > as necessary.

But to be useful, that "handler code" must be written and such code must
follow a standard interface for the OS used.  Consider the trivial task
that one Emacs instance wants to drop some text to a second Emacs
instance.  How would we trigger the drop event on that second instance?

 > ​Each window has a 'visible' attribute.  Are you saying this is not
 > accurate these days?​

Yes.  The GTK manual says that

   Modern composited windowing systems with pervasive transparency make
   it impossible to track the visibility of a window reliably,

 >> (1) ‘frame-list-z-order’ would have to be able to return all windows on
 >> ​​
 >> your system
 >
 >
 > ​Is it likely we could build a multi-platform primitive ​that would supply
 > that information given what you have said?

At least for top-level windows.  This will work as long a child windows
are fully contained by their parents which IIUC is not necessarily true
for macOS systems.

 >> and (2) a function would be needed to get the attributes of
 >> ​​
 >> those windows.
 >
 >
 > ​2 seems straightforward.

How accurate these attributes will be depends on the windowing system
used.  Look at how hard frame_geometry occasionally works to just get
the real screen estate of an Emacs frame.

martin




Reply | Threaded
Open this post in threaded view
|

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

Robert Weiner-2
On Sun, Oct 15, 2017 at 5:40 AM, martin rudalics <[hidden email]> wrote:

Even if the Emacs frame is covered by another application's frame,
nothing prevents us from having that covered Emacs frame accept the
drop.  We could even give frames a "no-accept-drops" parameter and this
way have a drop on such frames pass the drop through to yet another
frame below that does accept drops.

​Yes.  My point is that there should be some extension to Emacs'
reporting of window system events that allows a user of such
information to know whether any other application occluded the
Emacs frame at the time and point of release.  Then in cases
where this information can be gleaned from the external window
manager, it can be used in programs.  The user program is still
free to allow a drop to go through in such cases but only if
desired.

​​

​​
> I guess you are saying that Emacs drag events must start and end within
​​
> Emacs frames.  I think about it a bit differently.  Since the mouse can
​​
> move in and out of Emacs frames and release events can occur (in logical
​​
> Z-ordered OS window space) outside of Emacs, yet still register with Emacs
​​
> (when the release occurs within the geometry of a frame but the frame is
​​
> covered by another app's window), I think Emacs event handling should
​​
> return different information when the release frame is not the topmost
​​
> OS-level window at the point of release.  Then handler code could dispatch
​​
> as necessary.
​​

​​
But to be useful, that "handler code" must be written and such code must
​​
f
​​
o
​​
l
​​
l
​​
o
​​
w
​​
​​
a
​​
​​
s
​​
t
​​
a
​​
n
​​
d
​​
a
​​
rd interface for the OS used.

​It is not only drag-and-drop that we are interested in.  We
often want to simply call different functions based on whether
the drag release was inside or outside of Emacs.  For example,
Hyperbole now uses a drag release outside of Emacs to clone the
window depressed upon into a new frame.​

​​
  Consider the trivial task
​​

​​
that one Emacs instance wants to drop some text to a second Emacs
​​
instance.  How would we trigger the drop event on that second instance?

​Yes, you would need to follow a common drag-and-drop protocol.
I don't understand why that is an issue if that is what you want
to do.

​​

> ​Each window has a 'visible' attribute.  Are you saying this is not
​​
> accurate these days?​
​​

​​
Yes.  The GTK manual says that
​​

​​
  Modern composited windowing systems with pervasive transparency make
​​
  it impossible to track the visibility of a window reliably,

For programmatic purposes when Emacs receives a mouse button
drag release event, we only care about whether the topmost
window-system window at the point of release is an Emacs frame
or not.  If at that point, it is occluded by another window,
we don't care how transparent that window is and whether the
Emacs frame can be "seen" but only whether it is logically
the window clicked upon.  Again, even if it is not, we can
process the event as if it were *if we so choose* but having
the choice is the key issue here.

​​

​​

​​
>> (1) ‘frame-list-z-order’ would have to be able to return all windows on
​ 
your system
​​
>
​​
> ​Is it likely we could build a multi-platform primitive ​that would supply
​​
> that information given what you have said?
​​

​​
At least for top-level windows.  This will work as long a child windows
​​
are fully contained by their parents which IIUC is not necessarily true
​​
for macOS systems.

​Could you give a concrete example of where this might be a problem
so I could test code against it?
​​

​​
>
​​
> and (2) a function would be needed to get the attributes of
​​
 those windows.
​​
​​
​​
​​
​​
​​
​​
​​

​I have figured that part out from the macOS APIs.
Bob
Reply | Threaded
Open this post in threaded view
|

bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window

martin rudalics
 > ​Yes, you would need to follow a common drag-and-drop protocol.
 > I don't understand why that is an issue if that is what you want
 > to do.

Wasn't that something _you_ wanted to do?  If not then we can obviously
ignore it.

 > For programmatic purposes when Emacs receives a mouse button
 > drag release event, we only care about whether the topmost
 > window-system window at the point of release is an Emacs frame
 > or not.  If at that point, it is occluded by another window,
 > we don't care how transparent that window is and whether the
 > Emacs frame can be "seen" but only whether it is logically
 > the window clicked upon.  Again, even if it is not, we can
 > process the event as if it were *if we so choose* but having
 > the choice is the key issue here.

So I warned here about possible problems with "visibility" once and will
drop this issue.

 >> At least for top-level windows.  This will work as long a child windows
 >> ​​
 >> are fully contained by their parents which IIUC is not necessarily true
 >> ​​
 >> for macOS systems.
 >
 >
 > ​Could you give a concrete example of where this might be a problem
 > so I could test code against it?

Hardly.  Child windows are a separate problem because, for example, on X
you currently cannot drop files on them - the drop goes to the parent
window instead.

 >>> and (2) a function would be needed to get the attributes of
 >> ​
 >> ​​
 >>   those windows.
 >> ​​
 >> ​​
 >> ​​
 >> ​​
 >> ​​
 >> ​​
 >> ​​
 >> ​​
 >>
 >
 > ​I have figured that part out from the macOS APIs.

Window attributes are a problem on X.  You will learn about that as soon
as you try to adapt your code for it.

martin