bug#19482: Changing to big font cause display problem

[Jan D.]

Hi.

I redid the whole INNER_TO_OUTER thing, and now handle all sides.
The macros INNER_TO_OUTER are removed.

        Jan D.

> 25 feb 2015 kl. 19:25 skrev Jan D. <jan.h.d@swipnet.se>:
> 
> 
>> 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.
> 
> 
> 
>