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

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Anders Lindgren <andlind <at> gmail.com>,  Keith David Bershatsky <esq <at> lawlist.com>
Cc: 21415 <at> debbugs.gnu.org
Subject: bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame
Date: Mon, 14 Sep 2015 15:39:46 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.