bug#14795: height parameter inconsistent in new vs existing frames when tool-bar is enabled

bug#14795: height parameter inconsistent in new vs existing frames when tool-bar is enabled

[Juanma Barranquero]

Package: emacs


This happens since at least 22.1, and I think has been discussed
before on emacs-devel, but I've been unable to find the reference.

  emacs -Q

 (let ((params '((height . 25))))
  (make-frame params)  ;; f1
  (modify-frame-parameters (make-frame) params))  ;; f2

  f1 = 28 lines
  f2 = 25 lines

Adding (tool-bar-lines . 0) to params, both frames are 25 lines.

Obviously, when creating the frame Emacs is allowing three additional
lines as space for the toolbar. tool-bar-mode defaults to 3 in a newly
created frame, at least once it has been displayed:

(let ((f (make-frame)))
  (cons (frame-parameter f 'tool-bar-lines)
        (progn
          (sit-for 0)
          (frame-parameter f 'tool-bar-lines))))

=> (1 . 3)

Does that happen in all platforms? If so, shouldn't we make the
meaning of the height frame parameter consistent in all its uses?

bug#14795: height parameter inconsistent in new vs existing frames when tool-bar is enabled

[Juanma Barranquero]

Martin pointed out in emacs-devel that frame.c:x_figure_window_size()
includes the following comment:

  /* Add the tool-bar height to the initial frame height so that the
     user gets a text display area of the size he specified with -g or
     via .Xdefaults.  Later changes of the tool-bar height don't
     change the frame size.  This is done so that users can create
     tall Emacs frames without having to guess how tall the tool-bar
     will get.  */
  if (toolbar_p && FRAME_TOOL_BAR_LINES (f))

I remain unconvinced. That's mixing apples and oranges. If UI commands
(like -g) and UI settings (like X resources) should interpret the
frame height as meaning the client area, so be it. But then we should
decouple these from the `height' frame parameter, because it doesn't
really make sense to say that `height' means client area height when
creating a frame, but total frame height when modifying it.

bug#14795: height parameter inconsistent in new vs existing frames when tool-bar is enabled

[martin rudalics]

 >   /* Add the tool-bar height to the initial frame height so that the
 >      user gets a text display area of the size he specified with -g or
 >      via .Xdefaults.  Later changes of the tool-bar height don't
 >      change the frame size.  This is done so that users can create
 >      tall Emacs frames without having to guess how tall the tool-bar
 >      will get.  */
 >   if (toolbar_p && FRAME_TOOL_BAR_LINES (f))
 >
 > I remain unconvinced. That's mixing apples and oranges. If UI commands
 > (like -g) and UI settings (like X resources) should interpret the
 > frame height as meaning the client area, so be it. But then we should
 > decouple these from the `height' frame parameter, because it doesn't
 > really make sense to say that `height' means client area height when
 > creating a frame, but total frame height when modifying it.

What did you expect?  It's impossible to tell what a frame's height or
width is :-(

martin

bug#14795: height parameter inconsistent in new vs existing frames when tool-bar is enabled

[Jan Djärv]

Hello.

5 jul 2013 kl. 00:52 skrev Juanma Barranquero <lekktu@gmail.com>:

> Package: emacs
> 
> 
> This happens since at least 22.1, and I think has been discussed
> before on emacs-devel, but I've been unable to find the reference.
> 
>  emacs -Q
> 
> (let ((params '((height . 25))))
>  (make-frame params)  ;; f1
>  (modify-frame-parameters (make-frame) params))  ;; f2
> 
>  f1 = 28 lines
>  f2 = 25 lines
> 
> Adding (tool-bar-lines . 0) to params, both frames are 25 lines.
> 
> Obviously, when creating the frame Emacs is allowing three additional
> lines as space for the toolbar. tool-bar-mode defaults to 3 in a newly
> created frame, at least once it has been displayed:
> 
> (let ((f (make-frame)))
>  (cons (frame-parameter f 'tool-bar-lines)
>        (progn
>          (sit-for 0)
>          (frame-parameter f 'tool-bar-lines))))
> 
> => (1 . 3)
> 
> Does that happen in all platforms? If so, shouldn't we make the
> meaning of the height frame parameter consistent in all its uses?

It does not happen in all platforms.  NS and Gtk+ does not include toolbar or menubar, so your f1 and f2 are equal size (25).
Lucid/Motif on the other hand inlcude both menubar (1 line) and tool bar (2 lines) so you get different sizes for f1 and f2.  I would expect than X without toolkit behaves like Lucid/Motif.

IMHO, frame parameter like height should not include tool bar and menu bar.  Also, we should really not be talking about lines when specifying the height of the tool/menu bar, there is no need to.
The problem to fix this is you have to have access and knowledge of all ports, and modify them in parallel.  Not an easy task.  Also, this has been kind of low priority, it does not seem to lead to many user bug reports.

	Jan D.

bug#14795: height parameter inconsistent in new vs existing frames when tool-bar is enabled

[Juanma Barranquero]

On Fri, Jul 5, 2013 at 9:45 AM, martin rudalics <rudalics@gmx.at> wrote:

> What did you expect?  It's impossible to tell what a frame's height or
> width is :-(

I expect exactly what Jan says:

> IMHO, frame parameter like height should not include tool bar and menu bar.
> Also, we should really not be talking about lines when specifying the height
> of the tool/menu bar, there is no need to.