GNU bug report logs - #25818
25.2; frame moved off display does not return (OS X)

Previous Next

Full log

Message #56 received at 25818 <at> debbugs.gnu.org (full text, mbox):

From: Anders Lindgren <andlind <at> gmail.com>
To: "Charles A. Roelli" <charles <at> aurox.ch>
Cc: 25818 <at> debbugs.gnu.org, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>,
 martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#25818: 25.2; frame moved off display does not return (OS X)
Date: Mon, 27 Mar 2017 20:22:00 +0200

[Message part 1 (text/plain, inline)]

Hi!

Sorry for not getting back to you immediately.

Anyway, I did try your original patch. Unfortunately, the effect is as I
anticipated. When the patch is applied, if a frame is placed slightly
outside the display area, it will be moved back inside the borders.
Effectively, this means that you can't place the title bar above the top of
the display, which is possible (by design) with an unpatched Emacs. (By the
way, this is possible in Emacs on Windows as well.)

I use OS X 10.10.5 (Yosemite). I have "spaces" disabled, which allows an
Emacs frame to be stretched across multiple monitors.

To solve your problem, and to ensure that we don't break anything for my
use case, we would need to call "[super constrainFrameRect:frameRect
toScreen:screen];" only when the frame is determined to be fully outside
any monitor. This is not rocket science -- just iterate over all monitors
and check that the frame overlap at least one.

Sincerely,
    Anders Lindgren

On Sun, Mar 19, 2017 at 8:38 PM, Charles A. Roelli <charles <at> aurox.ch> wrote:

> Hi again,
>
> Sorry for taking a while to get back on this.
>
> Looking at this issue again, it would be helpful to know what version of
> OS X you use and whether you see the issue that I described in the first
> message of this thread (*), and also whether the patch I suggested stops
> frames from being placed above the top of the screen.  Because from what
> I can see, I don't see how the patch will prevent you from doing so,
> unless you have "Spaces" turned off.
>
> (*) One quick way of finding out is running something like
>     `(set-frame-position (selected-frame) 0 10000)' (best done from
>     `emacs -Q').  If the moved frame cannot be returned on-screen
>     programmatically, then you have the issue.  If it stays on-screen,
>     then you don't.
>
> My patch got rid of these lines:
>
> -#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_9
> -  // If separate spaces is on, it is like each screen is independent.
> There is
> -  // no spanning of frames across screens.
> -  if ([NSScreen screensHaveSeparateSpaces])
> -    {
> -      NSTRACE_MSG ("Screens have separate spaces");
> -      frameRect = [super constrainFrameRect:frameRect toScreen:screen];
> -      NSTRACE_RETURN_RECT (frameRect);
> -      return frameRect;
> -    }
> -#endif
>
> According to the Apple documentation, screensHaveSeparateSpaces()
> "returns a Boolean value that indicates whether each screen can have its
> own set of spaces.  This method reflects whether the “Displays have
> separate Spaces” option is enabled in Mission Control system
> preference. You might use the return value to determine how to present
> your app when in fullscreen mode."
>
> So the idea of this code was to constrain a frame only if "Spaces" is
> enabled, right?  I assume then, that if you have "Spaces" turned on (but
> even if you don't necessarily use the feature), then frames are
> prevented from going entirely off-screen (which is a must for OS X).
>
> The reason I ask this is because I have no idea whether the problem
> exists in Emacs on newer versions of OS X.  If it doesn't, then the fix
> can be added only for OS X < 10.9.
>

[Message part 2 (text/html, inline)]

Previous Next

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