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

[martin rudalics]

>> (((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