[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: Andreas Politz
Subject: bug#5721: Feature request: Function that returns absolute coordinates
Date: Sun, 29 Sep 2013 22:25:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

I may be badly confused, but here is how I understand this.  We have two
Windows (which may be the same, depending on tool-kit) FRAME_X_WINDOW I
and FRAME_OUTER_WINDOW O .  Both display some widget and I is a child of
O.  The fn x_real_positions (usually) takes O and traverses the tree up
to the last Window before the root window.

| Root window
| T : The WM TOP window
| +----
| | X: Some other WM window, border, title, whatever
| +------
| +--------

Then it computes I - T as [xy]_pixels_diff and it doesn't matter what
the WM displays in T or X or if these windows even exist.

I suppose with GTK the Window I represents the innermost text widget,
i.e the Emacs frame-root-window.  That would explain, why
[xy]_pixels_diff already seem to contain internal-border-width, the
toolbar (left + top), menu-bar etc.

>From this there are two questions: a) Does

     T = (frame->top_left, frame->top_pos)

always hold, and b) what does I stand for (e.g. is the menu-bar included
or not etc.) ?  If a) is true and b) can be known, as well as the
differences to the edit area (which seem to be zero for GTK), we are

Maybe a different approach would be to receive X11 events for Window I
and go from there ?

martin rudalics <address@hidden> writes:
> How to you establish that a value is "correct"?

I display a tool-tip at the position of window-absolute-pixel-edges and
look whether it displays at the right place, while changing the
variables (internal-border-width, etc.).


reply via email to

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