[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andreas Politz
Subject: bug#5721: Feature request: Function that returns absolute coordinates
Date: Sun, 29 Sep 2013 17:41:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

martin rudalics <address@hidden> 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).

> But note that for maximized and full-screen frames there usually are
> no outer borders and with full-screen frames there's no titlebar
> either.  How does your patch handle these?

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 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 (?).

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.

I think it should be C.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]