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

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

> > I'd like the request to be reopened, because the current function
> > `window-inside-absolute-pixel-edges' does not provide the requested
> > behaviour.
> 
> I think your analysis is correct but will leave it to Jan to decide how
> to proceed.
> 

I gave no opinion in the matter.  I think it is a mistake to let users access pixels.  It worked fine with X and no toolkit or Lucid/Motif.  But nowdays, window manager do strange things and so does toolkits (Gtk+ don't create separate windows for its widgets for example), so it is almost impossible to get right. 

	Jan D.



> > Suppose no fringes, and header-line.  All considerations for a GTK build.
> >
> > 0--------------------------------------*
> > |           display                    |
> > | A----------------------------+       |
> > | |      emacs <at> foo.bar         +       |
> > | |-B------------------------+ +       |
> > | | |       toolbar          | |       |
> > | | +------------------------+ |       |
> > | | |       menubar          | |       |
> > | | C------------------------+ |       |
> > | | |                        | |       |
> > | | |       window           | |       |
> > | | |   D---------+          | |       |
> > | | |   | tooltip |          | |       |
> > | | |   +---------+          | |       |
> > | | +------------------------+ |       |
> > | *----------------------------*       |
> > |                                      |
> > *--------------------------------------*
> 
> Where did/do we put the internal borders of the frame?
> 
> > We have a buffer position D =
> > (D.x, D.y) in some window and want to display a tool-tip there. At the
> > moment,
> >
> >        (posn-x-y (posn-at-point))
> >
> > gives us a position relative to C, so we would need it's absolute
> > position.
> >
> > But `window-absolute-pixel-edges' gives the absolute position of
> >
> >     (C.x - (B.x - A.x), C.y - (B.y - A.y))
> >   = (A.x , C.y - (B.y - A.y)) ,
> >
> > that is, it does not account for the width and height (B - A) of the
> > window managers decorations.  Furthermore these sizes are unknown to the
> > lisp side, making it impossible to complete the desired task.
> 
> I'm not sure whether we can correctly retrieve the decorations always
> and everywhere.  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?
> 
> > So it seems to me that `window-absolute-pixel-edges' should return the
> > absolute position of C, such that the tool-tip (or other frame) may be
> > positioned at C + D.
> >
> > I noticed, that the frame struct already has members x_pixels_diff and
> > y_pixels_diff, such that
> >
> >     (x_pixels_diff, y_pixels_diff) = (B.x - A.x, B.y - A.y) ,
> >
> > such that we may compute C with this values.  So I propose extending
> > `calc_absolute_offset' by adding these pixel_diff values.  For GTK this
> > appears to be especially easy, since these diff values already account
> > for the tool-bar and menu-bar sizes.
> 
> martin
> 
> 





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.