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

["Jan Djärv" <jan.h.d@swipnet.se>]

Hello.

29 sep 2013 kl. 17:41 skrev Andreas Politz <politza@hochschule-trier.de>:

> martin rudalics <rudalics@gmx.at> writes:
> 
>> I'm not sure whether we can correctly retrieve the decorations always
>> and everywhere.
> 
> It seems to me, that x_real_positions (xfns.c) does the right thing
> independent of the WM, i.e. it searches the last parent before the root
> Window, assumes that it is the outermost Window of the frame and
> computes the difference to the inner Emacs window (FRAME_X_WINDOW).
> 

This is known to be wrong.  For example, if some Gtk+ version does create separate X windows for menu bar and tool bar, the approach gives the offset to the Emacs text area below the tool bar.

If Gtk+ does NOT use separate windows for the menu- and/or tool-bar, but instead uses the FRAME_X_WINDOW, you get the coordinates to the menu- and/or tool bar.

> 
> The patch works for me with GTK, with internal-border-width and
> full-screen set, with Xmonad as well as fluxbox.  `border-width' in
> make-frame does not seem to make any difference, it's probably set via a
> GTK style (?).  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 until I move the frame, i.e. x_real_positions gets called
> and is most likely due to GTK windows bee-ing only partially mapped.
> 
> I think we can figure this out, when it becomes clear, which absolute
> position `window-absolute-pixel-edges' should actually return.

Race conditions are common when a window manager is involved.  Another reason to keep pixels private and not export them to Elisp.

	Jan D..