From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.bugs Subject: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window Date: Thu, 12 Oct 2017 09:08:30 -0400 Message-ID: References: <83wp4e3nvx.fsf@gnu.org> <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <83vajwytja.fsf@gnu.org> <83poa4yqyq.fsf@gnu.org> <83376qouoj.fsf@gnu.org> <59DF2260.5030204@gmx.at> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113755ca73294c055b593e36" X-Trace: blaine.gmane.org 1507813824 12884 195.159.176.226 (12 Oct 2017 13:10:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 12 Oct 2017 13:10:24 +0000 (UTC) Cc: Alan Third , 28620@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 12 15:10:16 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2dFb-0001TY-J0 for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Oct 2017 15:10:11 +0200 Original-Received: from localhost ([::1]:45424 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2dFf-0000ph-No for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Oct 2017 09:10:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42601) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2dFY-0000mt-Nc for bug-gnu-emacs@gnu.org; Thu, 12 Oct 2017 09:10:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2dFS-0007YJ-GI for bug-gnu-emacs@gnu.org; Thu, 12 Oct 2017 09:10:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54558) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e2dFS-0007Xq-Cw for bug-gnu-emacs@gnu.org; Thu, 12 Oct 2017 09:10:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e2dFS-0006wq-2y for bug-gnu-emacs@gnu.org; Thu, 12 Oct 2017 09:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Weiner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Oct 2017 13:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28620 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28620-submit@debbugs.gnu.org id=B28620.150781375326640 (code B ref 28620); Thu, 12 Oct 2017 13:10:02 +0000 Original-Received: (at 28620) by debbugs.gnu.org; 12 Oct 2017 13:09:13 +0000 Original-Received: from localhost ([127.0.0.1]:35006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2dEf-0006vc-Cg for submit@debbugs.gnu.org; Thu, 12 Oct 2017 09:09:13 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51389) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e2dEd-0006vN-Lb for 28620@debbugs.gnu.org; Thu, 12 Oct 2017 09:09:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2dEU-0006AU-B3 for 28620@debbugs.gnu.org; Thu, 12 Oct 2017 09:09:06 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42553) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2dEU-0006AE-66 for 28620@debbugs.gnu.org; Thu, 12 Oct 2017 09:09:02 -0400 Original-Received: from mail-qt0-f169.google.com ([209.85.216.169]:43793) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1e2dET-0005MT-T1 for 28620@debbugs.gnu.org; Thu, 12 Oct 2017 09:09:01 -0400 Original-Received: by mail-qt0-f169.google.com with SMTP id j58so2365490qtj.0 for <28620@debbugs.gnu.org>; Thu, 12 Oct 2017 06:09:01 -0700 (PDT) X-Gm-Message-State: AMCzsaWsVqXCmgf7FJxPKssqwDR84Z+K5bMCPgA3PaIA5KxLNtrZcLhF gs8ESAJvQsdqo55Xi73BAeF5bRdZMKlE9+HDvRc= X-Google-Smtp-Source: ABhQp+T91ZbPv/4NHPxsgmBtpuZPhoOEvEdQdv8UQRWYXFA80zNjMmalIEt1oeSrd0mllW2cNs4oDaTRyKHk8oyQXzo= X-Received: by 10.200.54.220 with SMTP id b28mr3262346qtc.186.1507813741503; Thu, 12 Oct 2017 06:09:01 -0700 (PDT) Original-Received: by 10.237.34.225 with HTTP; Thu, 12 Oct 2017 06:08:30 -0700 (PDT) In-Reply-To: <59DF2260.5030204@gmx.at> X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:138272 Archived-At: --001a113755ca73294c055b593e36 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 12, 2017 at 4:05 AM, martin rudalics 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 releas= e > > 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. =E2=80=8BI 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. =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > Is there any way to deal with external window z-order layering such tha= t > =E2=80=8B=E2=80=8B > > one can tell within Emacs whether the topmost OS-level window at an > =E2=80=8B=E2=80=8B > > absolute mouse position is an Emacs frame or not? > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Not really. Compositing window managers on X no more allow to track the > =E2=80=8B=E2=80=8B > visibility of windows reliably. So while we can discern the visibility > =E2=80=8B=E2=80=8B > of our own (window manager) windows based on what we store in their > =E2=80=8B=E2=80=8B > asscociated frames' 'visible' slots, we can't do that for windows of > =E2=80=8B=E2=80=8B > other applications. And processing whatever else XGetWindowAttributes > =E2=80=8B=E2=80=8B > returns for another application's window might not be trivial either. > =E2=80=8BJust FYI, I am using the macOS window manager, not X, though as yo= u 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. =E2=80=8B > > =E2=80=8B=E2=80=8B > It should be poss > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > ible to do what you want on Windows (where the debugger > =E2=80=8B=E2=80=8B > also notifies you > =E2=80=8B=E2=80=8B > when an Emacs frame is obscured) though. =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8BWell, one platform would be a good start.=E2=80=8B 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 --001a113755ca73294c055b593e36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Oct 12, 2= 017 at 4:05 AM, martin rudalics <rudalics@gmx.at> wrote:
> So if I have 2 f= rames, 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 relea= se
> 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.

=E2=80=8BI t= hink it is a feature that Emacs receives an event for this but a defect tha= t it can't distinguish when f2 is atop an external window or not and th= us whether the event was actually directed at f2 or not.

=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> Is there any way to deal with exter= nal window z-order layering such that
=E2=80=8B=E2=80=8B
> one can tell within Emacs whether t= he topmost OS-level window at an
=E2=80=8B=E2=80=8B
> absolute mouse position is an Emacs= frame or not?
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
Not really.=C2=A0 Compositing window man= agers on X no more allow to track the
=E2=80=8B=E2=80=8B
visibility of windows reliably.=C2=A0 So= while we can discern the visibility
=E2=80=8B=E2=80=8B
of our own (window manager) windows base= d on what we store in their
=E2=80=8B=E2=80=8B
asscociated frames' 'visible'= ; slots, we can't do that for windows of
=E2=80=8B=E2=80=8B
other applications.=C2=A0 And processing= whatever else XGetWindowAttributes
=E2=80=8B=E2=80=8B
returns for another application's wi= ndow might not be trivial either.

=E2=80=8BJust = 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-or= dering for all windows in order to be able to select and raise windows when= they are behind others.=C2=A0 So you are saying that they don't publis= h this information in any useful way that Emacs can obtain, right?

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

Mouse wheel events are also del= ivered to the topmost Z-order window without either raising the window or s= witching focus.

So the window manager always knows where it should d= eliver 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 it= s frames or over the window of an another application.

=E2=80=8B

=E2=80=8B=E2=80=8B
It should be poss
=E2=80=8B=E2= =80=8B
=E2=80=8B=E2=80=8B
ible to do what you want on = Windows (where the debugger
=E2=80=8B=E2=80=8B
also notifies you
=E2=80=8B= =E2=80=8B
when an Emacs frame is obscured) though.
=E2=80= =8B=E2=80=8B
=E2=80=8B=E2=80=8BWell, one platform would be a good start.= =E2=80=8B=C2=A0 What would the pseudo-code look like to check whether or no= t an Emacs frame was uppermost at the point of mouse release?

= Thanks,

Bob

--001a113755ca73294c055b593e36--