From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Newsgroups: gmane.emacs.bugs Subject: bug#5721: Feature request: Function that returns absolute coordinates Date: Sun, 29 Sep 2013 20:09:31 +0200 Message-ID: <1E552DE5-8FD1-45B9-A18B-B1532C6108CE@swipnet.se> References: <4B9E4521.9030909@yahoo.co.jp> <87fvsoemnj.fsf@hochschule-trier.de> <52480060.7020309@gmx.at> <87mwmvtz26.fsf@hochschule-trier.de> <6CBDC204-ABA9-41D4-BD59-4B66DF82B9D9@swipnet.se> <4A35A160-E728-4617-A65E-D79EC75B88D2@swipnet.se> <87eh87tug6.fsf@hochschule-trier.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1380478213 14585 80.91.229.3 (29 Sep 2013 18:10:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 29 Sep 2013 18:10:13 +0000 (UTC) Cc: 5721@debbugs.gnu.org To: Andreas Politz Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 29 20:10:17 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VQLRf-0001Hp-Co for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Sep 2013 20:10:15 +0200 Original-Received: from localhost ([::1]:45561 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VQLRe-0001eR-UU for geb-bug-gnu-emacs@m.gmane.org; Sun, 29 Sep 2013 14:10:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54499) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VQLRX-0001cW-S3 for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2013 14:10:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VQLRT-0002C2-9f for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2013 14:10:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36764) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VQLRT-0002Aj-5g for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2013 14:10:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VQLRS-0004yE-D3 for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2013 14:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Sep 2013 18:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 5721 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 5721-submit@debbugs.gnu.org id=B5721.138047817919069 (code B ref 5721); Sun, 29 Sep 2013 18:10:02 +0000 Original-Received: (at 5721) by debbugs.gnu.org; 29 Sep 2013 18:09:39 +0000 Original-Received: from localhost ([127.0.0.1]:45055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VQLR4-0004xT-2A for submit@debbugs.gnu.org; Sun, 29 Sep 2013 14:09:38 -0400 Original-Received: from mail01.bdtv.se ([176.10.222.34]:34445) by debbugs.gnu.org with smtp (Exim 4.80) (envelope-from ) id 1VQLQz-0004xF-Sh for 5721@debbugs.gnu.org; Sun, 29 Sep 2013 14:09:35 -0400 Original-Received: (qmail 8985 invoked by uid 89); 29 Sep 2013 18:09:32 -0000 Original-Received: from h-46-59-42-57.na.cust.bahnhof.se (HELO coolsville.localdomain) (boel.djarv@bdtv.se@46.59.42.57) by mail01.bdtv.se with ESMTPA; 29 Sep 2013 18:09:32 -0000 Original-Received: from [172.20.199.13] (unknown [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id E57761A0271; Sun, 29 Sep 2013 18:09:31 +0000 (UTC) In-Reply-To: <87eh87tug6.fsf@hochschule-trier.de> X-Mailer: Apple Mail (2.1510) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:78807 Archived-At: Hello. 29 sep 2013 kl. 19:21 skrev Andreas Politz = : > Jan Dj=E4rv writes: >=20 >>> This is known to be wrong. For example, if some Gtk+ version does >>> create separate X windows [...] >=20 > So, it depends on the toolkit and in some cases the tool-kit's = version. >=20 >> Forgot to mention that the window manager window that the title bar = is >> drawn in does not need to be a parent of any Emacs X window. In that >> case you can not get the size of the decorations at all. >>=20 >=20 > ,,does not need'' does not mean that any window manager does this. = Care > to give an example ? =20 Some versions of Compiz and other composite managers. >=20 > Also the size of the decoration doesn't really matter, as long as we = can > figure out the difference between the absolute frame position and the > start of the edit window. Or could it also be possible, that the > frame's absolute position (left, top) does point to the coordinates of = a > window of which the inner Emacs window is not a child ? If "frame" includes the window decorations, yes. >=20 >=20 >>>> [...] Anyway the only problem I sometimes ran into is a race >>>> condition, resulting in y_pixels_diff being to small. But this is = only >>>> temporarily [...] >=20 >>> Race conditions are common when a window manager is involved. >>> Another reason to keep pixels private and not export them to Elisp. >=20 > The request came from the author of auto-complete, a package which > displays completion candidates and their documentation with overlays = and > tool-tips at point. I'd like to see this move forward and, in the = end, > use undecorated frames instead. Without this function, this is > impossible without external programs. BTW any other recent editor = does this > (e.g. = http://cdn3.cybernetnews.com/wp-content/uploads/2008/06/notepad-5.png), > so I doubt that it's 'impossible'. I doubt the applcation do it by calculating offsets of positions based = on where on the screen the top/left corner happens to be on the screen. = It is quite easy in a toolkit to=20 add a transient-for window and do some translate coordinates between = them. No need for absolute coordinates at all. That is all taken care = of by the toolkit that knows the ins and outs of the X windows involved, = and has access to private data the application has not. >=20 > -ap >=20 > P.S.: I tried the patch on a bare --with-x-toolkit=3Dno build and it = seems > to give the correct values. Of course, the whole thing with absolute pixel calculations was = developed with bare X in mind. Jan D.