From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#28620: Interact directly on Emacs bug#28620: mouse drag event records wrong release window Date: Sun, 15 Oct 2017 11:40:10 +0200 Message-ID: <59E32CFA.5080405@gmx.at> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1508060473 1807 195.159.176.226 (15 Oct 2017 09:41:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Oct 2017 09:41:13 +0000 (UTC) Cc: Alan Third , 28620@debbugs.gnu.org To: rswgnu@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 15 11:41:09 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 1e3fPu-00080f-3q for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Oct 2017 11:41:06 +0200 Original-Received: from localhost ([::1]:56617 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3fQ1-0005l2-KD for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Oct 2017 05:41:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39694) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3fPu-0005kk-1x for bug-gnu-emacs@gnu.org; Sun, 15 Oct 2017 05:41:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e3fPq-0000XS-RI for bug-gnu-emacs@gnu.org; Sun, 15 Oct 2017 05:41:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60505) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e3fPq-0000XM-O8 for bug-gnu-emacs@gnu.org; Sun, 15 Oct 2017 05:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e3fPq-0005Mk-Gb for bug-gnu-emacs@gnu.org; Sun, 15 Oct 2017 05:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Oct 2017 09:41: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.150806043420580 (code B ref 28620); Sun, 15 Oct 2017 09:41:02 +0000 Original-Received: (at 28620) by debbugs.gnu.org; 15 Oct 2017 09:40:34 +0000 Original-Received: from localhost ([127.0.0.1]:40953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3fPO-0005Ls-3A for submit@debbugs.gnu.org; Sun, 15 Oct 2017 05:40:34 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:59063) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e3fPM-0005Lc-DT for 28620@debbugs.gnu.org; Sun, 15 Oct 2017 05:40:32 -0400 Original-Received: from [192.168.1.100] ([46.125.250.23]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Mc9U3-1dmPV201Tz-00JYNJ; Sun, 15 Oct 2017 11:40:15 +0200 In-Reply-To: X-Provags-ID: V03:K0:vGSCNXEr076weuVQ0zJ86pjQVruB39e8tO3HEk0QXCMbM5hSb2G 5U+crDvWY5zydQJZjvHVu5b18NhIDZEvdKZoNSbR62o4TrNLgivSY41sQEgn6rLBRI+/ZNK pyX/pilycgG/YrPcvHHjekRhQl6zTkm5PNwU2xczmoFyBWxyhtcgh7L85+RUa0LWO8MbDrD S04BButiIDjjh5J0hp3CA== X-UI-Out-Filterresults: notjunk:1;V01:K0:5QbZCc0juLQ=:SN1jc99XkNIQQf+FLB+zMS xsIoJYovJ/aniRyrbhvYgsWBHbJVsTxQSIv3dWsV3BYFXpBWP4zvWTxjjHegcQ3MvYe/r7ZpN MIkbRiCPZCzoMqy3Ga3qZoBJxhSTGXbjTsNzBuzEgyfhD5OikmcYdnobnTBMPszMQQkLWB/GU nAy6xn/YwN5W0rlF9bAQXhrJEFU+O1a4PNJpPJr0BZH1yvVeAE39qaAcLPebDfdFsnb1rBqua lQNKLs/GqmVxSwmg5beKDC64Yh3/W1Ieui2sLXLWg0QIY4xx4Dd4oYPHO+3PbonrqEYwvc3gb 83lZLjCUpF3mVaSE/8hVsZ9lArlBCrgjiIqrOJuw7VNu1Fio6E9w/PEpiDwL0/otEMAi7W5Rk 1knsYZUS0O6tmX4CNZUKbu/QFWzDf31Y+Xvx/dQ+IS+M4rBTeV+ZqBFRF8P467dcXcmFM6hiY JF0w6vSdC6MqpuqliWy5M0OXXNQyIvSr9tPtKyUX73BoThtuLxbUZI2DIdgRD4Vt7HPApfopl BMSW/jnLyJFErYMoCjR3H+lhakd9RWLmZMS+3Xs9gE/B+Bu4oYWfz+GVs86RO04tmpN51615w AuVCBju+hP+ioM7qA53XC/6/7EFZgE5oTGiCE9Jo0bOi8TQtEScgXFHeUZApcPjq8Rtwj4WTl ITfHy41hQvSpUiG0tqE2UU7dx1wc+IOGjRUlBWJHKYfzS27XTX63AAGpONc4ZyLVKXeXKZ56n vU5BL8Bs28CTqK4wxVPEeBWSAuQU2Y9+qKPKIJYK70gXoGrNaHISsEROCCjOTy2PuBf0nv+O 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:138447 Archived-At: > =E2=80=8BOk, that indicates that drag-and-drop from Emacs to external = applications > is unlikely but it still leaves the issue of recognizing whether a dra= g > 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 i= n > 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 withi= n > Emacs frames. I think about it a bit differently. Since the mouse ca= n > move in and out of Emacs frames and release events can occur (in logic= al > Z-ordered OS window space) outside of Emacs, yet still register with E= macs > (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 disp= atch > 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? > =E2=80=8BEach window has a 'visible' attribute. Are you saying this i= s not > accurate these days?=E2=80=8B 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) =E2=80=98frame-list-z-order=E2=80=99 would have to be able to ret= urn all windows on >> =E2=80=8B=E2=80=8B >> your system > > > =E2=80=8BIs it likely we could build a multi-platform primitive =E2=80= =8Bthat 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 >> =E2=80=8B=E2=80=8B >> those windows. > > > =E2=80=8B2 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