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

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

I may be badly confused, but here is how I understand this.  We have two
Windows (which may be the same, depending on tool-kit) FRAME_X_WINDOW I
and FRAME_OUTER_WINDOW O .  Both display some widget and I is a child of
O.  The fn x_real_positions (usually) takes O and traverses the tree up
to the last Window before the root window.

+------
| Root window
+----
| T : The WM TOP window
| +----
| | X: Some other WM window, border, title, whatever
| +------
| | O : FRAME_OUTER_WINDOW
| +--------
| | I : FRAME_X_WINDOW

Then it computes I - T as [xy]_pixels_diff and it doesn't matter what
the WM displays in T or X or if these windows even exist.

I suppose with GTK the Window I represents the innermost text widget,
i.e the Emacs frame-root-window.  That would explain, why
[xy]_pixels_diff already seem to contain internal-border-width, the
toolbar (left + top), menu-bar etc.

From this there are two questions: a) Does

     T = (frame->top_left, frame->top_pos)

always hold, and b) what does I stand for (e.g. is the menu-bar included
or not etc.) ?  If a) is true and b) can be known, as well as the
differences to the edit area (which seem to be zero for GTK), we are
good.

Maybe a different approach would be to receive X11 events for Window I
and go from there ?

martin rudalics <rudalics@gmx.at> writes:
> How to you establish that a value is "correct"?

I display a tool-tip at the position of window-absolute-pixel-edges and
look whether it displays at the right place, while changing the
variables (internal-border-width, etc.).

-ap