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

[martin rudalics]

>>> No, ns-auto-hide-menu-bar does not move the frame at all.
>>
>> OK.  But doesn't it remove the constraint that a frame's rectangle must
>> start somehwere at or below (0, 0)?
>
> When the menu bar is visible, OS X doesn't allow windows above the menu
> bar.

I'm not sure I understand: Do you mean here "OS X doesn't allow windows
above the top of the screen"?

> When it is hidden, it's not possible to drag a window above the top of
> the screen.

I've never been able to "drag" a window above the top of the screen
because on all machines I know of the title bar is the handle for
dragging.

> However, OS X allows an application to place a window above the
> top of the screen -- the code in Emacs simply ensures that Emacs itself
> doesn't hinder this.

Does this "OS X allows an application to place a window above the top of
the screen" hold _only_ when the menu bar is hidden or does it hold
regardless of that?  What's such a restriction good for anyway?

> -- the code in Emacs simply ensures that Emacs itself
> doesn't hinder this.

Because Emacs "normally" advices OS X to constrain the frame to the
screen.  Correct?

> By the way, when I use Win32, I also place the title bar above the top of
> the screen,

Why?  Do you never use the fullscreen feature?

> so this is not a feature that is unique to the OS X port. Of
> course, for a frame the be placed above the top of the screen, the user
> must explicitly placed it there. A frame should never "just happen" to be
> placed above the top of the screen.

It will happen when it's too large and you specify negative values for
its position.

> Hiding the menu bar only hides the menu bar -- it does not move the frame
> or hide the title bar.

OK.

> However, when the menu bar is hidden the user can place the top of the
> frame at a negative offset (i.e. above the top of the screes), but this
> must be done explicitly. Most users won't use this feature, but it's
> important to those that do.

OK.  The "when" might be an answer to one of my questions above.

>> But how comes that for Keith the frame is apparently placed above the
>> top of the screen although he didn't specify it?
>
> Clearly, this is a bug -- the frame should not be placed above the top of
> the screen in this case.
>
> In Emacs 24, this didn't happen. Why this happens in Emacs 25, I don't
> know, but clearly this is not the way we want the system to work.
>
> The desired behavior is to place the top of the frame at the top of the
> screen, or right below the menu bar (if it's present). If a `top' attribute
> is present, the window should be placed accordingly. Also, a frame that is
> too high for the screen should stretch down below the bottom of the screen,
> like it did in Emacs 24.

Agreed.

> I have tried to trace it through the various functions -- it seems that
> Emacs tries to place the frame at the top of the screen (which is where we
> want it) but at a later phase, the frame is somehow moved and/or constraint
> to an incorrect location. This may take some time, however, given that I
> have small children and a full time job, but I will try to find some time
> for it during this or (more likely) next week.

Fine.

Thanks for your efforts, martin