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

Previous Next

Package: emacs;

Reported by: Juanma Barranquero <lekktu <at> gmail.com>

Date: Thu, 4 Jul 2013 22:54:02 UTC

Severity: wishlist

Merged with 25

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log


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




This bug report was last modified 10 years and 140 days ago.

Previous Next


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