GNU bug report logs - #5721
Feature request: Function that returns absolute coordinates

Previous Next

Full log

View this message in rfc822 format

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Andreas Politz <politza <at> hochschule-trier.de>
Cc: martin rudalics <rudalics <at> gmx.at>, 5721 <at> debbugs.gnu.org
Subject: bug#5721: Feature request: Function that returns absolute coordinates
Date: Sun, 29 Sep 2013 20:09:31 +0200

Hello.

29 sep 2013 kl. 19:21 skrev Andreas Politz <politza <at> hochschule-trier.de>:

> Jan Djärv <jan.h.d <at> swipnet.se> writes:
> 
>>> This is known to be wrong.  For example, if some Gtk+ version does
>>> create separate X windows [...]
> 
> So, it depends on the toolkit and in some cases the tool-kit's version.
> 
>> 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.
>> 
> 
> ,,does not need'' does not mean that any window manager does this.  Care
> to give an example ?  

Some versions of Compiz and other composite managers.

> 
> 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.

> 
> 
>>>> [...]  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 [...]
> 
>>> Race conditions are common when a window manager is involved.
>>> Another reason to keep pixels private and not export them to Elisp.
> 
> 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 
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.

> 
> -ap
> 
> P.S.: I tried the patch on a bare --with-x-toolkit=no 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.