bug#19482: Changing to big font cause display problem

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

Hi.

> 23 feb 2015 kl. 07:22 skrev Jan D. <jan.h.d@swipnet.se>:
> 
> Hi.
> 
> martin rudalics skrev den 2015-02-22 19:52:
>> >> IIUC FRAME_OUTER_TO_INNER_DIFF_Y is the height of title bar, tool bar
>> >
>> > Only for external toolbar.
>> 
>> ... and external menubar, yes.  BTW, when do we get the menu bar in the
>> title bar?  One line less to count ...
> 
> Sadly there is no standard for how to do this.  Ubuntu (and others) seems to be moving to having a global menubar a'la MacOS/OSX.
> Then you never have to count it.  I think this is semiautomatic, but I wonder if Emacs takes it into account, I'll have to test it.

I could not get a definite answer to this as the semiautomatic move of the menubar doesn't happen anymore.  Maybe I need a setting.

> 
>> 
>> > The define has just not been updated with something like
>> FRAME_TOOLBAR_WIDTH:
>> >
>> > #define FRAME_OUTER_TO_INNER_DIFF_X(f) \
>> >       ((f)->output_data.x->x_pixels_outer_diff)
>> > #define FRAME_OUTER_TO_INNER_DIFF_Y(f)          \
>> >       ((f)->output_data.x->y_pixels_outer_diff   \
>> >        + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f))
>> 
>> Sure.  But I probably can't change it without changing its clients as
>> well.
> 
> I'm not sure.  There are only a few usages, and I think not taking toolbal width into account is probably a bug.  Will check this also.

It is a bug, popups will popup at the wrong position.  We need to track all four sides.
I'm implementing that.

> 
>> 
>> >>    And at
>> >> least here a maximized frame shows decorations only on two orthogonal
>> >> sides so the above is certainly not always correct.  Do you have any
>> >> better ideas?
>> >
>> > You can always compute them on the fly with something similar to what
>> x_real_positions does and take into account the lower right corner as
>> well as the upper left corner.
>> 
>> I don't get the borders reported separately so I always distribute the
>> space occupied by the one visible border among it and the non-existent
>> border.  Not a great deal obviously, but I'm sure that mouse position
>> calculations are off by a few pixels in that case.
>> 
> 
> What I meant was that x_real_positions gets the upper left corner for the outer window and the inner window and calls the difference OUTER_TO_INNER_DIFF.  But you can take the width/height of the outer/inner window and also calculate exactly the diff of all sides.

But I still think you are confused about what is outer and inner window here.  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, 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.

So what you have calculated is not the window manager window sizes, because inner_to_outer width is not taken into account.  There actually is no window with width FRAME_PIXEL_WIDTH + 2 * border in the Gnome 3 case.  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.

So what are you trying to calculate?  Is it the window manager window geometry, or the geometry of the largest Emacs created window?

	Jan D.