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

Previous Next

Full log

View this message in rfc822 format

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: bug#5721: Feature request: Function that returns absolute coordinates
Date: Sun, 29 Sep 2013 18:05:43 +0200

Hello.

29 sep 2013 kl. 18:02 skrev Jan Djärv <jan.h.d <at> swipnet.se>:

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

Forgot to mention that the window manager window that the title bar is drawn in does not need to be a parent of any Emacs X window.  In that case you can not get the size of the decorations at all.

	Jan D.

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

Previous Next

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