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

[martin rudalics]

> The patch isn't perfect, as in I only tested it with GTK.  Are you
> talking about the frame parameter `border-width' or
> `internal-border-width' ?

I mean the outer border width as established by the window manager.

> I think, as long as we can now the absolute
> position of (the window at) C, this should probably make no difference,
> since it shouldn't matter how much of the space of (C - A) is spent on
> the border or a title (?).

C - A might be the outer border width.  But it might also include a left
scroll- or toolbar IIUC.

> The patch works for me with GTK, with internal-border-width

This surprises me because I don't see where internal-border-width is
handled in calc_absolute_offset.  Is it because f->left_pos does already
account for the 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 (?).

I think so.

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

ISTR two problems from the last time I looked into this: You cannot
always get C - A (or B - A) from the system and with fullscreen and
maximized frames A is occasionally less than zero.

martin