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

[martin rudalics <rudalics@gmx.at>]

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