bug#19482: Changing to big font cause display problem

[Jan D.]

Hi.

> 25 feb 2015 kl. 11:33 skrev martin rudalics <rudalics@gmx.at>:
> 
> >> 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.
> 
> 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.

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

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

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.
The non-external tool bar, the non-external menubar are in the inner window.  
But toolkit menubar/toolbar are in the outer window.

> 
> >>  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.
> 
> Where does Emacs set external borders?  Do we really control that?
> 

In xfns.c, for the toolkit (Motif/Lucid case):

  XtSetArg (al[ac], XtNborderWidth, f->border_width); ac++;

for the non-toolkit, and tooltip case (xfns.c) in the call to XCreateWindow.
For the Gtk+ case we don't set any, the default is taken from wathever theme is 
in place.  The border is usually 0 pixel.


> > You must specify what you mean by outer and
> > inner.
> 
> I did that and it's still cited at the top of this post.
> 
> > FRAME_OUTER_TO_INNER_DIFF_Y gives the diff between the outmost
> > Emacs created window and the window manager window.
> 
> No.  It's the diff between the _top edge_ of the outmost Emacs created
> window and that of the window manager window (using your parlance).

Correct.

> What's missing is the diff between the _bottom edge_ of the outmost
> created window and that of the window manager window.

Yes.

> 
> >>  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.
> 
> I am interested in the size of the "window manager window".

Ok.

> 
> > Only borders do.
> 
> 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.

> 
> >>  > 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 last one is not needed in this discussion.  Can we agree that your
> "window manager window" is the one returned by FRAME_OUTER_WINDOW?

No, because that is not true.

>  And
> that the "outmost Emacs created window" is the one whose sizes are
> specified by FRAME_PIXEL_WIDTH and FRAME_PIXEL_HEIGHT?

Yes, that is FRAME_OUTER_WINDOW.

>  If so, then
> 
> "outer window" is equivalent to "window manager window"

No.

> 
> and
> 
> "inner window" is equivalent to "outmost Emacs created window"
> 

No.  There are three windows involved, se figure above.

> >> Are you sure?  Does FRAME_OUTER_TO_INNER_DIFF_X not include the extra 10
> >> pixels you mentioned above?
> >
> > Yes they do.
> 
> Then my calculation should handle this case (and obviously seems to fail
> for the external border at the bottom of such a frame).
> 
> >> 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.
> 
> But their size is counted in the "inner window" aka "outmost Emacs
> created window".  Otherwise we could not really handle a frame with
> side-by-side windows where two or more scrollbars would have to be
> counted.

I was wrong, scrollbars are on the inner window.  Don't know where I got that 
from.

> 
> > as well as non-external (i.e. text) menu and non-external toolbar.
> 
> These are part of the inner window.

Yes, the non-external are.  The external are not.

> 
> > But for frame-inner-size you subtract menu and tool bar.  So this is
> > not the size of the largest Emacs created window.
> 
> You're right.  What I earlier said about the value of 'frame-inner-size'
> was probably misleading.  Let's forget about 'frame-inner-size' for the
> moment, it's too confusing.
> 
> > What are you doing with these sizes?
> 
> 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.
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?

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

> Also I want the sizes of external tool and menu bar for debugging things
> like the various maximized/fullsize variants.

That makes sense.

        Jan D.