bug#4535: toolkit dependence of frame-height

bug#4535: toolkit dependence of frame-height

[Glenn Morris]

As far as I can tell, the result of (frame-height) on GNU/Linux
depends on the X toolkit on the following way:

gtk        : excludes both tool-bar and menu-bar
motif      : includes tool-bar (height = 2?), excludes menu-bar
lucid      : like motif
no toolkit : includes both tool-bar and menu-bar (height = 1)
-nw        : includes menu-bar

The motif and lucid values seems inconsistent with the Elisp manual:

     These values include the internal borders, and windows' scroll
     bars and fringes (which belong to individual windows, not to the
     frame itself), but do not include menu bars or tool bars (except
     when using X without an X toolkit).

I am happy to update the documentation, if the current behaviour (and
my understanding of it) is correct, or not going to be changed. (It is
rather confusing though.)


Some previous discussion:

http://lists.gnu.org/archive/html/bug-gnu-emacs/2007-12/msg00103.html

and to some extent bug #25

bug#4535: toolkit dependence of frame-height

[Jan D.]

Your understanding is correct. Please update the docs. However, it has  
been an old goal to unify this, i.e. make all toolkits behave as Gtk.

      Jan D.

23 sep 2009 kl. 08.57 skrev Glenn Morris <rgm@gnu.org>:

>
> As far as I can tell, the result of (frame-height) on GNU/Linux
> depends on the X toolkit on the following way:
>
> gtk        : excludes both tool-bar and menu-bar
> motif      : includes tool-bar (height = 2?), excludes menu-bar
> lucid      : like motif
> no toolkit : includes both tool-bar and menu-bar (height = 1)
> -nw        : includes menu-bar
>
> The motif and lucid values seems inconsistent with the Elisp manual:
>
>     These values include the internal borders, and windows' scroll
>     bars and fringes (which belong to individual windows, not to the
>     frame itself), but do not include menu bars or tool bars (except
>     when using X without an X toolkit).
>
> I am happy to update the documentation, if the current behaviour (and
> my understanding of it) is correct, or not going to be changed. (It is
> rather confusing though.)
>
>
> Some previous discussion:
>
> http://lists.gnu.org/archive/html/bug-gnu-emacs/2007-12/msg00103.html
>
> and to some extent bug #25
>
>
>

bug#4535: toolkit dependence of frame-height

[Glenn Morris]

"Jan D." wrote:

> Your understanding is correct. Please update the docs.

Will do.

Do the menu bar and tool bar always have height 1 and 2 respectively,
or are these numbers variable and/or approximate?

bug#4535: toolkit dependence of frame-height

[martin rudalics]

 > Do the menu bar and tool bar always have height 1 and 2 respectively,
 > or are these numbers variable and/or approximate?

It depends on what "always have height 1 and 2" stand for.  On Windows I
can easily make the menubar occupy three "lines" of my screen estate.
And AFAICT such behavior can make frame-size calculations completely
random because Emacs (probably due to limitations of the Windos API)
does not allow me to get the actual size of my frame in lines.

martin

bug#4535: toolkit dependence of frame-height

[Glenn Morris]

martin rudalics wrote:

>> Do the menu bar and tool bar always have height 1 and 2 respectively,
>> or are these numbers variable and/or approximate?
>
> It depends on what "always have height 1 and 2" stand for. 

Well, I hadn't thought it through, because lines may have a variable
height. Duh.

And I can increase the buffer font-size many times over without
changing the result of frame-height (or -width), so now I don't
understand what "number of lines available for display" in the doc of
frame-height means.

I guess it means number of lines in units of the default face? So I
guess that's what my original question meant.

> On Windows I can easily make the menubar occupy three "lines" of my
> screen estate. And AFAICT such behavior can make frame-size
> calculations completely random because Emacs (probably due to
> limitations of the Windos API) does not allow me to get the actual
> size of my frame in lines.

I'm not going to be able to document the Windows behaviour in any
case; maybe you'd like to do that?

bug#4535: toolkit dependence of frame-height

[martin rudalics]

 >> It depends on what "always have height 1 and 2" stand for.
 >
 > Well, I hadn't thought it through, because lines may have a variable
 > height. Duh.
 >
 > And I can increase the buffer font-size many times over without
 > changing the result of frame-height (or -width), so now I don't
 > understand what "number of lines available for display" in the doc of
 > frame-height means.
 >
 > I guess it means number of lines in units of the default face? So I
 > guess that's what my original question meant.

Most frame variables seem to have a historical interpretation which
somehow got lost with the evolution of GUIs and the adaptations to
different operating systems and toolkits.  Thinking of frame sizes in
lines and columns is asking for trouble in anything but a text-only
environment.  Documenting the current behavior seems next to impossible
to me.

 > I'm not going to be able to document the Windows behaviour in any
 > case; maybe you'd like to do that?

I can't.  I don't understand it.  But I'll gladly read anything you come
up with for other platforms ;-)

martin

bug#4535: marked as done (toolkit dependence of frame-height)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

Your message dated Sat, 10 Oct 2009 20:09:49 -0400
with message-id <m0ljji6baq.fsf@fencepost.gnu.org>
and subject line Re: bug#4535: toolkit dependence of frame-height
has caused the Emacs bug report #4535,
regarding toolkit dependence of frame-height
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
4535: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4535
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 3064 bytes --]

From: Glenn Morris <rgm@gnu.org>
To: bug-gnu-emacs@gnu.org
Subject: toolkit dependence of frame-height
Date: Wed, 23 Sep 2009 02:57:54 -0400
Message-ID: <l2k4zqywp9.fsf@fencepost.gnu.org>


As far as I can tell, the result of (frame-height) on GNU/Linux
depends on the X toolkit on the following way:

gtk        : excludes both tool-bar and menu-bar
motif      : includes tool-bar (height = 2?), excludes menu-bar
lucid      : like motif
no toolkit : includes both tool-bar and menu-bar (height = 1)
-nw        : includes menu-bar

The motif and lucid values seems inconsistent with the Elisp manual:

     These values include the internal borders, and windows' scroll
     bars and fringes (which belong to individual windows, not to the
     frame itself), but do not include menu bars or tool bars (except
     when using X without an X toolkit).

I am happy to update the documentation, if the current behaviour (and
my understanding of it) is correct, or not going to be changed. (It is
rather confusing though.)


Some previous discussion:

http://lists.gnu.org/archive/html/bug-gnu-emacs/2007-12/msg00103.html

and to some extent bug #25



[-- Attachment #3: Type: message/rfc822, Size: 1781 bytes --]

From: Glenn Morris <rgm@gnu.org>
To: 4535-done@emacsbugs.donarmstrong.com
Subject: Re: bug#4535: toolkit dependence of frame-height
Date: Sat, 10 Oct 2009 20:09:49 -0400
Message-ID: <m0ljji6baq.fsf@fencepost.gnu.org>


I have tried to document this as well as I can (though I don't feel I
understand it all).