bug#19482: Changing to big font cause display problem

[Jan D.]

martin rudalics skrev den 2015-02-25 08:34:
>  > 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.

Then you should never need to bother with _OUTER_TO_INNER_DIFF.

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

It never does.  It only contains the title bar.

>  The title bar and the external
> borders are definitely part of the window manager window.

The title bar is, but borders are not.  It is entirely possible to set 
border on any X window, regardless of where it is in the hierarchy.
So the external borders Emacs sets is on the outmost Emacs window, not 
on 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.

You must specify what you mean by outer and inner. 
FRAME_OUTER_TO_INNER_DIFF_Y gives the diff between the outmost Emacs 
created window and the window manager 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?

As I said, I'm implementing this.  But it seems you don't need this.  If 
you are only interested in the size of the Emacs created outmost window, 
OUTER_TO_INNER_DIFF does not apply.  Only borders do.

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

Again, define inner and outer.  We are using confusing terminology.
I suggest
window manager window
Outmost Emacs created window.
Inner Emacs created 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?

Yes they do.

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

Not in the X sense, they are attached to the outmost Emacs created 
window.  Thats one of the reasons we have that window, the other is 
external menubar and external tool bar.

Only Emacs native scrollbar are attached to the inner Emacs window, as 
well as non-external (i.e. text) menu and non-external toolbar.

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

But for frame-inner-size you subtract menu and tool bar.  So this is not 
the size of the largest Emacs created window.

What are you doing with these sizes?

        Jan D.