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 #171 received at 5721 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Politz <politza <at> hochschule-trier.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 5721 <at> debbugs.gnu.org
Subject: Re: bug#5721: Feature request: Function that returns absolute
 coordinates
Date: Sun, 29 Sep 2013 17:41:53 +0200
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).

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

-ap




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.