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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14795 in the body.
You can then email your comments to 14795 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: height parameter inconsistent in new vs existing frames when tool-bar
 is enabled
Date: Fri, 5 Jul 2013 00:52:22 +0200

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?

Message #8 received at 14795 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: 14795 <at> debbugs.gnu.org
Subject: Re: bug#14795: height parameter inconsistent in new vs existing
 frames when tool-bar is enabled
Date: Fri, 5 Jul 2013 01:11:35 +0200

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.

Message #11 received at 14795 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14795 <at> debbugs.gnu.org
Subject: Re: bug#14795: height parameter inconsistent in new vs existing frames
 when tool-bar is enabled
Date: Fri, 05 Jul 2013 09:45:31 +0200

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

Message #14 received at 14795 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14795 <at> debbugs.gnu.org
Subject: Re: bug#14795: height parameter inconsistent in new vs existing
 frames when tool-bar is enabled
Date: Fri, 5 Jul 2013 11:29:04 +0200

Hello.

5 jul 2013 kl. 00:52 skrev Juanma Barranquero <lekktu <at> 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.

Message #17 received at 14795 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14795 <at> debbugs.gnu.org
Subject: Re: bug#14795: height parameter inconsistent in new vs existing
 frames when tool-bar is enabled
Date: Fri, 5 Jul 2013 11:51:21 +0200

On Fri, Jul 5, 2013 at 9:45 AM, martin rudalics <rudalics <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.