From: Robert Weiner <rsw@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: Possible Bug: Mouse drag event records wrong window for release when crossing frames
Date: Fri, 29 Sep 2017 09:03:59 -0400 [thread overview]
Message-ID: <CA+OMD9h=QzU+USEAXGmQDYkA5r3TAn=DVzc2XL8RPxdNYj5j3Q@mail.gmail.com> (raw)
In-Reply-To: <59CE058D.3010607@gmx.at>
[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]
On Fri, Sep 29, 2017 at 4:34 AM, martin rudalics <rudalics@gmx.at> wrote:
> > The behavior is the same either way. It is definitely a bug in Emacs
> 25.2
> > and 25.3 as I have confirmed it on both MacOS and Windows 7 using just
> > default mouse-1 drags between frames.
>
> Do you mean that earlier Emacsen behave differently in this regard?
No, just that I tested only with those versions.
> >> The start event seems to look OK. As for the end event, an X-coordinate
> >> of -1373 does not look reasonable.
> >
> >
> > Right. Is a negative value ever valid in this context?
>
> I think so. For example if you want to move your frame to that position
> on the screen.
Ok.
> > My claim is that if you put 2 frames on screen (start with
> non-overlapping)
> > and drag mouse-1 from the text area of one to the second, that the drag
> > event generated upon the release of mouse-1 will contain frame1 rather
> than
> > frame2 (where the release happened).
>
> IIUC Emacs never was able to do that. Mouse dragging events so far make
> sense only for the one-frame case.
This needs to be fixed as it is a very natural gesture to
move between frames. For the text area, this is moving
between windows which just happen to occupy different frames.
> What you want involves much more
> trickery: If you have two target frames covering the same screen
> position, which one would you choose when releasing the mouse at that
> position? Probably the one higher in the z-order.
Yes. It may be easier to think of it in terms of the window
of release rather than the frame as one will almost always
need to know the window as well.
One initial way to decrease the complexity is to make this work
only when both the depress and release commands set the selected
window. Then the posn- functions would have a unique window to
report.
> But only Emacs 26
>
> can handle that and we would have to write routines to do it.
Ok
.
>
>
>
> Or
>
>
>
>
>
>
>
> the one that gets focus during mouse tracking because your window
>
> manager has some sort of focus-follows-mouse installed? Then you would
>
>
>
>
>
>
>
>
>
>
>
>
>
> have to query the focus when you release the mouse. Non-trivial.
See above.
Thanks much for the feedback. I can say that if this is
implemented, it will lead to improved user interfaces and
faster inter-frame control in many instances.
Bob
[-- Attachment #2: Type: text/html, Size: 7812 bytes --]
next prev parent reply other threads:[~2017-09-29 13:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-26 6:06 Possible Bug: Mouse drag event records wrong window for release when crossing frames Robert Weiner
2017-09-27 8:11 ` martin rudalics
2017-09-27 13:44 ` Robert Weiner
2017-09-29 8:34 ` martin rudalics
2017-09-29 13:03 ` Robert Weiner [this message]
2017-09-29 18:19 ` martin rudalics
2017-09-29 17:31 ` Stefan Monnier
2017-09-29 18:20 ` martin rudalics
2017-09-29 19:08 ` Robert Weiner
2017-09-29 19:20 ` Stefan Monnier
2017-09-29 19:25 ` Robert Weiner
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+OMD9h=QzU+USEAXGmQDYkA5r3TAn=DVzc2XL8RPxdNYj5j3Q@mail.gmail.com' \
--to=rsw@gnu.org \
--cc=emacs-devel@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.