bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19482: Changing to big font cause display problem


From: martin rudalics
Subject: bug#19482: Changing to big font cause display problem
Date: Wed, 25 Feb 2015 08:34:39 +0100

> It is a bug, popups will popup at the wrong position.  We need to track all 
four sides.
> I'm implementing that.

Thanks.

> But I still think you are confused about what is outer and inner
> window here.

For the purpose of `x-frame-geometry' the outer window of a frame on X
is the one returned by FRAME_OUTER_WINDOW.  The inner window is the one
whose size is given by FRAME_PIXEL_WIDTH and FRAME_PIXEL_HEIGHT.
`x-frame-geometry' should return in 'frame-outer-size' the size of the
_outer window_ including any external toolbar or menubar "attached to
that window" (I'm not interested in "floating" bars).  This way, Emacs
can check whether the outer window fits conceptually into the working
area of its display.

> In the macro OUTER_TO_INNER_DIFF outer refers to the
> window that the windowmanager puts as Emacs parent.  "Inner" here is
> actually the outermost Emacs created X window, and "outer" is the
> window manager window.  So outer contains the title bar,

IIUC the only problem is whether the "window manager window" does
contain the external toolbar/mmenubar.  The title bar and the external
borders are definitely part of the window manager window.

> but this:
>
>    outer_width = FRAME_PIXEL_WIDTH (f) + 2 * border;
>    outer_height = (FRAME_PIXEL_HEIGHT (f)
>              + FRAME_OUTER_TO_INNER_DIFF_Y (f)
>              + FRAME_OUTER_TO_INNER_DIFF_X (f));
>
>
> is just plain wrong, because for you are calculating something that
> does not correspond to any real window.  For example, on Gnome 3 the
> window manager puts in a window that is 10 pixels wider on both sides,
> so it can do shadow effects.  But the border is still one or zero
> pixels.

FRAME_OUTER_TO_INNER_DIFF_Y gives me only the offset of the top left
corner, that is, the difference of the top edge of the outer window and
the inner window.  I don't know how to get the difference between the
bottom edge of the Emacs window and the bottom edge of the outer window.
So I approximate.  This approximation obviously goes wrong when the left
and bottom borders are not the same size.  Can you tell me a better way?

> So what you have calculated is not the window manager window sizes,
> because inner_to_outer width is not taken into account.

FRAME_OUTER_TO_INNER_DIFF_X gives me the offset of the left edge of the
inner window wrt the outer window.  The only thing I can do is multiply
it by two.  As mentioned earlier, if these differences are not
symmetric, for example, because one border is larger than the other, the
information provided is wrong.  Again, it's the best approximation I can
come up with so far.

> There
> actually is no window with width FRAME_PIXEL_WIDTH + 2 * border in the
> Gnome 3 case.

Are you sure?  Does FRAME_OUTER_TO_INNER_DIFF_X not include the extra 10
pixels you mentioned above?

> For Gtk+/Motif/Lucid, we create a window outside the
> frame (i.e. text editing part) that contains the tool bar if external,
> menu bar and scroll bar.  But that window is not this size either, the
> width would in general contain the scroll bar for example.

That would be devastating.  Scroll bars are part of the inner window.

> So what are you trying to calculate?  Is it the window manager window
> geometry, or the geometry of the largest Emacs created window?

The sizes of the outer window aka window manager window.  The size of
the largest Emacs created window is returned by `x-frame-geometry' for
comparison purpose only (via 'frame-inner-size').

martin





reply via email to

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