bug#19482: Changing to big font cause display problem

[Jan D.]

> 25 feb 2015 kl. 18:33 skrev martin rudalics <rudalics@gmx.at>:
> 
> >> Then how do I get the size of the outer window (the size of the object
> >> returned by FRAME_OUTER_WINDOW)?
> >>
> >
> > There is a difference between FRAME_OUTER_WINDOW and the window manager 
> > window.  The window manager window is outside FRAME_OUTER_WINDOW, and its 
> > parent.
> > OUTER_TO_INNER gives the diff between the window manager window and 
> > FRAME_OUTER_WINDOW.  The size of FRAME_OUTER_WINDOW is 
> > FRAME_PIXEL_WIDTH/HEIGHT + borders.
> 
> With "borders" you mean external borders, I presume.

Yes.

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

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

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.

> 
> >>>> 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.
> >>
> >> Are you sure?
> >
> > Like a gazillion percent sure.
> 
> OK.  Then we apparently have the following misunderstanding.  You seem
> to say that the window manager window does not contain the Emacs outer
> window but only the title bar.

No, the window manager contains them both, the title bar above Emacs outer 
window.

>  I say that the window manager window
> contains the title bar and the Emacs outer window.

Right.

> 
> >>   External menu and tool bars bars are normally in between
> >> title bar and the inner window so how can they not be counted?
> >
> > ---------------------------------------------------------
> > |   Window manager window, title bar
> > | --------------------------------------------------------
> > | | Emacs outer window, menu bar
> > | | tool bar
> > | | ------------------------------------------------------
> > | | | Emacs inner window, text and scrollbar
> > | | |
> >
> 
> We're probably meaning the same thing but you do not include nested
> windows, so for you the Emacs inner window is not part of the Emacs
> outer window.

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.

> 
> > Things get more complicated for when Emacs is compiled without a
> > toolkit (i.e. non-external menu bar) or the non-external toolbar.  For
> > the no toolkit case, there is no Emacs outer window.
> 
> But it's still where the internal borders are?

They are in the inner window.

> 
> >> I also need title bar, external tool and menu bar.
> >
> > Please note that a window manager window is just one way a window
> > manager can set a title bar.  There are other ways, esp. for composite
> > managers, and (I guess) Wayland.  In these cases, there is no way we
> > can know the size of the title bar.
> 
> Then we can do nothing in these cases.

Right.

> 
> >> Give applications a possibility to calculate the maximimum size of a
> >> frame so that it remains entirely visible within the work area of its
> >> display.  This could be used, for example, to guarantee that setting the
> >> default font doesn't make a frame larger than the display.
> >>
> >
> > This is a job for the window manager.  Some window managers constrain the 
> > size of Emacs, some do not.
> 
> If I deliberately set the frame size to some large value, there's
> obviously no reason to constrain that.  But if I increase the default
> font I'd probably want my frame stay within the bounds of the display.

Some window managers already do that for you.

> At least the behavior described by the OP where the frame's height is
> constrained by the display while the width isn't doesn't sound very
> reasonable.
> 
> > Also, you do need to take into account things like panels that the
> > desktop can contain, and handle the fact that the panels may be
> > different on different workspaces and monitors.  Are you handling the
> > case when Emacs is too high for one monitor but there is another
> > monitor below that shows the rest?  Are you handling the same case,
> > but this time the monitor below shows a different workspace and the
> > rest is not shown below?
> 
> No.  We already do not everywhere handle these cases correctly.  But my
> restriction would be "safe" in the sense that my frame's size would
> never exceed that of the frame we produce currently.

Then how do you allow for spanning between monitors?

> 
> > This is really a window manager function, we should not have it in
> > Emacs at all.  If someone sets a font so large that Emacs is not fully
> > visible, let them.  Tell them to get another window manager if they
> > want Emacs constrained.  And how do we know what the user wants?
> > Someone might not want Emacs constrained (for example I don't).
> 
> The OP proposed an option to do that.

        Jan D.