bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics <rudalics@gmx.at>]

 >> (((name . "SyncMaster")
 >>>     (geometry 0 0 1600 1200)
 >>>     (workarea 0 23 1600 1173)
 >>>     (mm-size 432 324)
 >>>     (frames #<frame *scratch* 0x101099630>)
 >>>     (source . "NS"))
 >>>    ((name . "SyncMaster")
 >>>     (geometry 1600 0 1600 1200)
 >>>     (workarea 1600 0 1600 1200)
 >>>     (mm-size 432 324)
 >>>     (frames)
 >>>     (source . "NS")))
 >>>
 >>> Interestingly, the workarea of the primary screen is missing four pixels
 >>> (1200 - 1173 - 34) = 4.
 >>
 >> What was the 34 about?  I probably forgot.
 >
 >
 > "34" should be "23", which is the height of the menu bar.
 >
 > In other words, the effective work area seems to be lacking four pixels at
 > the bottom.
 >
 > I agree with you that I prefer a maximized frame to cover the entire
 > screen. I will try to do some experiments to see if it's possible, and if
 > so, we can discuss if we should modify Emacs to behave this way.

IIUC the Mac menu bar is what other systems call a task bar.  In that
case, a maximized frame should cover everything but the menu bar and a
fullboth frame should cover the entire screen.  Now if I understand you
correctly, Mac doesn't distinguish the various "zoomed" states - a
fullheight frame is just as "zoomed" as a fullscreen or maximized one.

 > Emacs calls the NextStep function `performZoom' without specifying a
 > height. The system, in turn, calls `windowWillUseStandardFrame:' with a
 > suggested frame with the height 1173 (when frame-resize-pixelwise is
 > non-nil).
 >
 > My guess is that we can override this, but I haven't verified this.

How does one specify a size with performZoom?  And does one performZoom
(to get a fullheight frame, say) followed by another one (to get a
fullboth frame, say) followed by toggling the button produce the initial
normal frame?

 > I got my write access rights today! Thanks for suggesting this.

Great!

martin