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

[Anders Lindgren <andlind@gmail.com>]

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

Hi,

>>> If ‘ns-auto-hide-menu-bar’ non-nil also moves the title bar off screen,
>>> you can't position the frame at (0, 0).  Or am I missing something?
>>
>> 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. When it is hidden, it's not possible to drag a window above the top of
the screen. 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.

By the way, when I use Win32, I also place the title bar above the top of
the screen, 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.


> I lost you.  I thought that ‘ns-auto-hide-menu-bar’ non-nil means to
> also automatically hide the title bar.  Am I wrong?

Yes, you are wrong!

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

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.


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

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.

/ Anders


On Mon, Sep 14, 2015 at 10:32 AM, martin rudalics <rudalics@gmx.at> wrote:

> >> If ‘ns-auto-hide-menu-bar’ non-nil also moves the title bar off screen,
> >> you can't position the frame at (0, 0).  Or am I missing something?
> >
> > 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)?
>
> > The user is
> > allowed to place the frame above the top of the screen, but this does not
> > occur automatically. In other words, a frame can be placed at (0, 0).
>
> But how comes that for Keith the frame is apparently placed above the
> top of the screen although he didn't specify it?
>
> > To answer your earlier questions. You were speculating about adding
> another
> > variable for "the auto hide frame title feature". However, I don't think
> > this is a good idea since there is no such feature. Hiding the frame
> title
> > requires the user to explicitly move the frame (or use a package that
> does
> > this, like my "multicolumn" package).
>
> I lost you.  I thought that ‘ns-auto-hide-menu-bar’ non-nil means to
> also automatically hide the title bar.  Am I wrong?
>
> martin
>
>

[-- Attachment #2: Type: text/html, Size: 6857 bytes --]