unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Robert Weiner <rsw@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>, martin rudalics <rudalics@gmx.at>,
	Alan Third <alan@idiocy.org>,
	28620@debbugs.gnu.org
Subject: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window
Date: Wed, 11 Oct 2017 21:35:13 -0400	[thread overview]
Message-ID: <CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@mail.gmail.com> (raw)
In-Reply-To: <CA+OMD9j04LF7u_ec1OKCb=7VUarYuTAwyEYD1fAokcUAxT5F4w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4722 bytes --]

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 <rsw@gnu.org> wrote:

> On Wed, Oct 11, 2017 at 1:16 PM, Robert Weiner <rsw@gnu.org> 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))
>

[-- Attachment #2: Type: text/html, Size: 11880 bytes --]

  reply	other threads:[~2017-10-12  1:35 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CA+OMD9gfe-sUm_er47UmPzrCmvSEjUP0TdsCapBxeiFQS=E1dg@mail.gmail.com>
     [not found] ` <83wp4e3nvx.fsf@gnu.org>
     [not found]   ` <DCD76686-AED1-4D1B-BF28-CAA693633E07@gmail.com>
     [not found]     ` <8360bx340d.fsf@gnu.org>
     [not found]       ` <CA+OMD9j9u1KTKFrQyGSVR43gcvmD16kqcVo9pw7dYhp+KULjcA@mail.gmail.com>
     [not found]         ` <8360bw19es.fsf@gnu.org>
     [not found]           ` <CA+OMD9h8i6DcxdS4pcrNxHiTbCmxZfU9=CqArJt9GKH8O6LPSw@mail.gmail.com>
2017-10-03 18:21             ` bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window Robert Weiner
2017-10-03 18:42               ` Eli Zaretskii
2017-10-03 18:53                 ` Robert Weiner
2017-10-03 22:40               ` Alan Third
2017-10-04  0:15                 ` Robert Weiner
2017-10-04 16:30                   ` Alan Third
2017-10-04 17:26                     ` Robert Weiner
2017-10-04 18:59                       ` Alan Third
2017-10-04 19:30                         ` Robert Weiner
2017-10-04 20:11                           ` Robert Weiner
2017-10-04 20:07                         ` Robert Weiner
2017-10-04 22:09                           ` Alan Third
2017-10-05  0:38                             ` Robert Weiner
     [not found]             ` <83vajwytja.fsf@gnu.org>
     [not found]               ` <CA+OMD9gtwbg4gZzFryWCteN-gHuwvvqTYhVf2WUmpznZ9jo+Ng@mail.gmail.com>
     [not found]                 ` <83poa4yqyq.fsf@gnu.org>
     [not found]                   ` <CA+OMD9gM_3qgioX_RhhDHWF9GYA7=6++Hq5im2nwcwtdKLyDnA@mail.gmail.com>
     [not found]                     ` <CA+OMD9g5dX8Dg92F1pRgYKt3j0yyg=8rBOpSc5SePPiodFnOWA@mail.gmail.com>
     [not found]                       ` <83376qouoj.fsf@gnu.org>
     [not found]                         ` <CA+OMD9hi52ZgCWFTSFPBEu2tOpF12kvHqpu8p4oi-f6jPdw2bA@mail.gmail.com>
2017-10-11 18:49                           ` Robert Weiner
2017-10-12  1:35                             ` Robert Weiner [this message]
2017-10-12  1:47                               ` Robert Weiner
2017-10-12  8:05                               ` martin rudalics
2017-10-12 13:08                                 ` Robert Weiner
2017-10-14  8:35                                   ` martin rudalics
2017-10-14 17:16                                     ` Robert Weiner
2017-10-14 18:47                                       ` Robert Weiner
2017-10-15  3:31                                         ` Robert Weiner
2017-10-15  9:40                                       ` martin rudalics
2017-10-16 16:31                                         ` Robert Weiner
2017-10-17  8:57                                           ` martin rudalics
2017-10-19 18:32                                             ` Robert Weiner
2017-10-20  7:55                                               ` martin rudalics
2017-10-20 14:26                                                 ` Robert Weiner
2017-10-21  8:05                                                   ` martin rudalics
2017-10-21 18:05                                                     ` Richard Stallman

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='CA+OMD9iLa=R+TTF_0HF2bMsgr-MGhZBqGc=BExRE3kzSj4zfAA@mail.gmail.com' \
    --to=rsw@gnu.org \
    --cc=28620@debbugs.gnu.org \
    --cc=alan@idiocy.org \
    --cc=eliz@gnu.org \
    --cc=rswgnu@gmail.com \
    --cc=rudalics@gmx.at \
    /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).