[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: martin rudalics
Subject: bug#5721: Feature request: Function that returns absolute coordinates
Date: Sun, 29 Sep 2013 20:46:50 +0200

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


reply via email to

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