GNU bug report logs - #5721
Feature request: Function that returns absolute coordinates

Previous Next

Package: emacs;

Reported by: irieshinsuke <at> yahoo.co.jp

Date: Mon, 15 Mar 2010 14:34:02 UTC

Severity: wishlist

Done: Jan Djärv <jan.h.d <at> swipnet.se>

Bug is archived. No further changes may be made.

Full log


Message #177 received at 5721 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Andreas Politz <politza <at> hochschule-trier.de>
Cc: martin rudalics <rudalics <at> gmx.at>, 5721 <at> debbugs.gnu.org
Subject: Re: bug#5721: Feature request: Function that returns absolute
 coordinates
Date: Sun, 29 Sep 2013 18:02:50 +0200
Hello.

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

> martin rudalics <rudalics <at> 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..





This bug report was last modified 11 years and 239 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.