bug#19482: Changing to big font cause display problem

["Jan D." <jan.h.d@swipnet.se>]

Hi.

> 25 feb 2015 kl. 20:00 skrev martin rudalics <rudalics@gmx.at>:
> 
> >>   So in
> >>
> >> #define FRAME_OUTER_TO_INNER_DIFF_Y(f)          \
> >>      ((f)->output_data.x->y_pixels_outer_diff   \
> >>       + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f))
> >>
> >> we calculate the height difference of the Emacs outer window and the
> >> Emacs inner window where y_pixels_outer_diff in this context stands for
> >> the external border only.  Correct?
> >
> > No.  As currently defined, this is the difference at the top, so it
> > includes the title bar if any. Also, I said the Gnome 3 window manager
> > puts a 10 pixel area for shading purposes.  y_pixels_outer_diff
> > contains these 10 pixels + borders.  Window managers may put extra
> > decorations around a window, those are also included.  Only if the
> > window manager adds nothing to the sides, and there is no title bar
> > does y_pixels_outer_diff represent the border only.
> 
> OK.  This is what I assumed initially.  So this macro specifies the
> distance of the top of the Emacs inner window from the top of the window
> manager window.

Yes, but it is buggy as it does not take into accout the case of the tool bar at the bottom.

> 
> >
> >>   And this
> >>
> >>   /* These many pixels are the difference between the outer window (i.e. the
> >>      left and top of the window manager decoration) and FRAME_X_WINDOW.  */
> >>   int x_pixels_diff, y_pixels_diff;
> >>
> >> is misleading because "outer window" here is not the same as
> >> "FRAME_OUTER_WINDOW".  So I'm still not sure: What do
> >> y_pixels_outer_diff and y_pixels_diff typically stand for?
> >
> 
> > y_pixels_outer_diff is typically the title bar height + the external
> > border.  Nowdays there are few window managers that add decorations at
> > the top except the title bar, but if they did, it would be added here
> > (like the 10 pixel shading area).
> 
> So this is the distance of the top of the Emacs outer window from the
> top of the window manager window plus the external border.

Yes.

> 
> > y_pixels_diff is the offsets to the FRAME_X_WINDOW, not the
> > FRAME_OUTER_WINDOW.  For the case with external menu bar and external
> > tool bar at the top, y_pixels_diff is y_pixels_outer_diff + menu bar
> > height + tool bar height. If there are no tool bar or menu bar, then
> > they become the same.
> 
> And how does this differ from FRAME_OUTER_TO_INNER_DIFF_Y?

I don't know, I think they would be the same.

> 
> > I do include nested windows in the picture above.  The inner window is nested inside the outer window, which in turn is nested inside the window manager window.
> >
> > It is a containment relationship.  Ithe inner window is contained inside the outer window.
> > The outer window is contained inside the window manager window.
> >
> >>   Now where do the external borders go in this drawing?  I
> >> considered them part of the window manager window.  You apparently
> >> consider them part of the Emacs outer window.  Right?
> >
> > In X speak they are part of the outer window.  X handles external
> > borders separate from windows, so you specify both width/height and
> > border width when you create a window.  They are part of the outer
> > window, because if you kill the window manager and run without any
> > window manager, the borders are still there.
> 
> That's confusing.  OT1H they are part of the outer window and OTOH they
> are drawn around the window manager window.

No, the border is drawn around the outer window.

>  This makes nesting
> impossible.  That is, the Emacs outer window cannot be contained in the
> windows manager window

The only purpose for a window manager windon is to contain other applications top level windows.

> 
> >> But it's still where the internal borders are?
> >
> > They are in the inner window.
> 
> But we don't count them in `frame-text-height'.

Ok.  That makes sense though, the inner border is not text.

> 
> > Then how do you allow for spanning between monitors?
> 
> You mean someone who increases the default font would expect the frame
> to span a second monitor.  That person would have to set the option in a
> way that it doesn't constrain the frame's size.

But if you want to span when the second monitor is connected, but constrain when there is only one?
There are so many corner cases here.  There will be bug reports if Emacs tries to constrain stuff.
The only one that has the full picture is the window manager, so it is its job, not Emacs.

	Jan D.