bug#5721: Feature request: Function that returns absolute coordinates

[Andreas Politz <politza@hochschule-trier.de>]

Jan Djärv <jan.h.d@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 ?  

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 ?


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

Just something that has to be dealt with.

Either way the function exists and we can try to fix it or remove it.  I
don't see what purpose it serves in it's current state.

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

-ap

P.S.: I tried the patch on a bare --with-x-toolkit=no build and it seems
to give the correct values.