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: Mon, 16 Oct 2017 12:31:06 -0400 Message-ID: References: <8360bx340d.fsf@gnu.org> <8360bw19es.fsf@gnu.org> <83vajwytja.fsf@gnu.org> <83poa4yqyq.fsf@gnu.org> <83376qouoj.fsf@gnu.org> <59DF2260.5030204@gmx.at> <59E1CC55.2090400@gmx.at> <59E32CFA.5080405@gmx.at> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113755ca542939055bac8abc" X-Trace: blaine.gmane.org 1508171560 3851 195.159.176.226 (16 Oct 2017 16:32:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 16 Oct 2017 16:32:40 +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 Mon Oct 16 18:32:35 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 1e48JW-0007dL-LV for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Oct 2017 18:32:27 +0200 Original-Received: from localhost ([::1]:34040 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e48Je-0003AW-3Q for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Oct 2017 12:32:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37330) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e48JC-0002qu-6n for bug-gnu-emacs@gnu.org; Mon, 16 Oct 2017 12:32:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e48J8-0004T4-OL for bug-gnu-emacs@gnu.org; Mon, 16 Oct 2017 12:32:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35418) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e48J8-0004Sw-LE for bug-gnu-emacs@gnu.org; Mon, 16 Oct 2017 12:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e48J8-0003ZJ-Di for bug-gnu-emacs@gnu.org; Mon, 16 Oct 2017 12:32: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: Mon, 16 Oct 2017 16:32: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.150817150713696 (code B ref 28620); Mon, 16 Oct 2017 16:32:02 +0000 Original-Received: (at 28620) by debbugs.gnu.org; 16 Oct 2017 16:31:47 +0000 Original-Received: from localhost ([127.0.0.1]:44099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e48It-0003Yp-9Q for submit@debbugs.gnu.org; Mon, 16 Oct 2017 12:31:47 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:46161) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e48Is-0003Yd-9g for 28620@debbugs.gnu.org; Mon, 16 Oct 2017 12:31:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e48Ij-0004Er-Vl for 28620@debbugs.gnu.org; Mon, 16 Oct 2017 12:31:41 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57653) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e48Ij-0004Eg-Rl for 28620@debbugs.gnu.org; Mon, 16 Oct 2017 12:31:37 -0400 Original-Received: from mail-qt0-f169.google.com ([209.85.216.169]:43851) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1e48Ij-0005Gx-EF for 28620@debbugs.gnu.org; Mon, 16 Oct 2017 12:31:37 -0400 Original-Received: by mail-qt0-f169.google.com with SMTP id j58so21803459qtj.0 for <28620@debbugs.gnu.org>; Mon, 16 Oct 2017 09:31:37 -0700 (PDT) X-Gm-Message-State: AMCzsaVEvOqWsxdI31kkfY11GKqD8WAwMwFz+X1VjqCKqS18MWQ8qAbt TGeHoYt0hjPWhJiRcnkkNJK88nSwdFQZMwNg4nA= X-Google-Smtp-Source: AOwi7QD0UUoSfBnjnQx6J17ocF2ZO5Ns457DjF2AdU1+1YCBL/tInKckcfYlY6Far57vOaLFHHcj+UvQjV5znMkPKco= X-Received: by 10.200.54.220 with SMTP id b28mr14299145qtc.186.1508171496825; Mon, 16 Oct 2017 09:31:36 -0700 (PDT) Original-Received: by 10.237.34.225 with HTTP; Mon, 16 Oct 2017 09:31:06 -0700 (PDT) In-Reply-To: <59E32CFA.5080405@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:138537 Archived-At: --001a113755ca542939055bac8abc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 15, 2017 at 5:40 AM, martin rudalics 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. =E2=80=8BYes. 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. =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > I guess you are saying that Emacs drag events must start and end within > =E2=80=8B=E2=80=8B > > Emacs frames. I think about it a bit differently. Since the mouse can > =E2=80=8B=E2=80=8B > > move in and out of Emacs frames and release events can occur (in logica= l > =E2=80=8B=E2=80=8B > > Z-ordered OS window space) outside of Emacs, yet still register with > Emacs > =E2=80=8B=E2=80=8B > > (when the release occurs within the geometry of a frame but the frame i= s > =E2=80=8B=E2=80=8B > > covered by another app's window), I think Emacs event handling should > =E2=80=8B=E2=80=8B > > return different information when the release frame is not the topmost > =E2=80=8B=E2=80=8B > > OS-level window at the point of release. Then handler code could > dispatch > =E2=80=8B=E2=80=8B > > as necessary. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > But to be useful, that "handler code" must be written and such code must > =E2=80=8B=E2=80=8B > f > =E2=80=8B=E2=80=8B > o > =E2=80=8B=E2=80=8B > l > =E2=80=8B=E2=80=8B > l > =E2=80=8B=E2=80=8B > o > =E2=80=8B=E2=80=8B > w > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > a > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > s > =E2=80=8B=E2=80=8B > t > =E2=80=8B=E2=80=8B > a > =E2=80=8B=E2=80=8B > n > =E2=80=8B=E2=80=8B > d > =E2=80=8B=E2=80=8B > a > =E2=80=8B=E2=80=8B > rd interface for the OS used. =E2=80=8BIt 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.=E2=80=8B =E2=80=8B=E2=80=8B > Consider the trivial task > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > that one Emacs instance wants to drop some text to a second Emacs > =E2=80=8B=E2=80=8B > instance. How would we trigger the drop event on that second instance? =E2=80=8BYes, 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. =E2=80=8B=E2=80=8B > > =E2=80=8B > > =E2=80=8BEach window has a 'visible' attribute. Are you saying this is= not > =E2=80=8B=E2=80=8B > > accurate these days?=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Yes. The GTK manual says that > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Modern composited windowing systems with pervasive transparency make > =E2=80=8B=E2=80=8B > 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. =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > >> (1) =E2=80=98frame-list-z-order=E2=80=99 would have to be able to retu= rn all windows on > =E2=80=8B > =E2=80=8B > your system > =E2=80=8B > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > > =E2=80=8BIs it likely we could build a multi-platform primitive =E2=80= =8Bthat would > supply > =E2=80=8B=E2=80=8B > > that information given what you have said? > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > At least for top-level windows. This will work as long a child windows > =E2=80=8B=E2=80=8B > are fully contained by their parents which IIUC is not necessarily true > =E2=80=8B=E2=80=8B > for macOS systems. =E2=80=8BCould you give a concrete example of where this might be a problem so I could test code against it? =E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > > and (2) a function would be needed to get the attributes of > =E2=80=8B > =E2=80=8B=E2=80=8B > those windows. > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8BI have figured that part out from the macOS APIs. =E2=80=8B Bob =E2=80=8B --001a113755ca542939055bac8abc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Oct 15, 2= 017 at 5:40 AM, martin rudalics <rudalics@gmx.at> 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.=C2=A0 We could even give frames a "no-accept-drops" paramet= er and this
way have a drop on such frames pass the drop through to yet another
frame below that does accept drops.

=E2=80=8BYes.= =C2=A0 My point is that there should be some extension to Emacs'
<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace">repor= ting of window system events that allows a user of such
information to kno= w whether any other application occluded the
Emacs frame at the time and p= oint of release.=C2=A0 Then in cases
where this information can be gleaned= from the external window
manager, it can be used in programs.=C2=A0 The u= ser program is still
free to allow a drop to go through in such cases but = only if
desired.

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

=E2=80=8B=E2=80=8B
> I guess you are saying that Emacs d= rag events must start and end within
=E2=80=8B=E2=80=8B
> Emacs frames.=C2=A0 I think about i= t a bit differently.=C2=A0 Since the mouse can
=E2=80=8B=E2=80=8B
> move in and out of Emacs frames and= release events can occur (in logical
=E2=80=8B=E2=80=8B
> Z-ordered OS window space) outside = of Emacs, yet still register with Emacs
=E2=80=8B=E2=80=8B
> (when the release occurs within the= geometry of a frame but the frame is
=E2=80=8B=E2=80=8B
> covered by another app's window= ), I think Emacs event handling should
=E2=80=8B=E2=80=8B
> return different information when t= he release frame is not the topmost
=E2=80=8B=E2=80=8B
> OS-level window at the point of rel= ease.=C2=A0 Then handler code could dispatch
=E2=80=8B=E2=80=8B
> as necessary.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
But to be useful, that "handler cod= e" must be written and such code must
=E2=80=8B=E2=80=8B
f
=E2=80=8B=E2=80=8B
o=E2=80=8B=E2=80=8B
l
=E2=80=8B=E2=80=8B
l
=E2=80=8B=E2=80=8B
o
=E2=80=8B=E2=80=8B
w
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
a
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
s
= =E2=80=8B=E2=80=8B
t
=E2=80=8B=E2=80=8B
a
=E2= =80=8B=E2=80=8B
n
=E2=80=8B=E2=80=8B
d
=E2=80= =8B=E2=80=8B
a
=E2=80=8B=E2=80=8B
rd interface for the = OS used.

=E2=80=8BIt is not only drag-and-drop that = we are interested in.=C2=A0 We
often want to simply call different functio= ns based on whether
the drag release was inside or outside of Emacs.=C2=A0= For example,
Hyperbole now uses a drag release outside of Emacs to clone = the
window depressed upon into a new frame.=E2=80=8B

=E2=80=8B=E2=80=8B
=C2=A0 Consider the= trivial task
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
that one Emacs instance wants to drop so= me text to a second Emacs
=E2=80=8B=E2=80=8B
instance.=C2=A0 How would we trigger the= drop event on that second instance?

=E2=80=8BYes, = you would need to follow a common drag-and-drop protocol.
I don't un= derstand why that is an issue if that is what you want
to do.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
=E2=80=8B=E2=80= =8B

=E2=80=8B
> =E2=80=8BEach window has a 'visible'= attribute.=C2=A0 Are you saying this is not
=E2=80=8B=E2=80=8B
> accurate these days?=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
Yes.=C2=A0 The GTK manual says that
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
=C2=A0 Modern composited windowing syste= ms with pervasive transparency make
=E2=80=8B=E2=80=8B
=C2=A0 it impossible to track the visibi= lity 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 Em= acs frame
or not.=C2=A0 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.=C2=A0 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.<= /div>

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

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

=E2=80=8B=E2=80=8B
>> (1) =E2=80=98frame-list-z-order= =E2=80=99 would have to be able to return all windows on
=E2=80= =8B=C2=A0
=E2=80=8B
your system
=E2=80= =8B
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B
> =E2=80=8BIs it likely we could buil= d a multi-platform primitive =E2=80=8Bthat would supply
=E2=80=8B=E2=80=8B
> that information given what you hav= e said?
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
At least for top-level windows.=C2=A0 Th= is will work as long a child windows
=E2=80=8B=E2=80=8B
are fully contained by their parents whi= ch IIUC is not necessarily true
=E2=80=8B=E2=80=8B
for macOS systems.

=
=E2=80=8BCould you give a concrete example of where this might be a probl= em
so I could test code against it?
=E2=80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B
> and (2) a function would be needed to get the= attributes of
=E2=80=8B
=E2=80=8B=E2=80=8B=C2=A0those windows.
=E2=80=8B=E2=80=8B
=E2=80= =8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B= =E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2= =80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80= =8B

=E2=80=8BI have figured that part o= ut from the macOS APIs.
=E2=80=8B
Bob
=E2=80=8B
--001a113755ca542939055bac8abc--