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

[martin rudalics <rudalics@gmx.at>]

 > 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