From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.bugs Subject: bug#25818: 25.2; frame moved off display does not return (OS X) Date: Mon, 27 Mar 2017 20:22:00 +0200 Message-ID: References: <58AEA232.4000708@gmx.at> <58B30634.1090904@gmx.at> <58B3DDBA.6060003@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113e3c7e6c63b9054bba6b33 X-Trace: blaine.gmane.org 1490639113 9666 195.159.176.226 (27 Mar 2017 18:25:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Mar 2017 18:25:13 +0000 (UTC) Cc: 25818@debbugs.gnu.org To: "Charles A. Roelli" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 27 20:25:09 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1csZK7-00016L-5r for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Mar 2017 20:24:59 +0200 Original-Received: from localhost ([::1]:48441 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csZKB-0001zU-9l for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Mar 2017 14:25:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38420) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csZII-0000Z6-Hr for bug-gnu-emacs@gnu.org; Mon, 27 Mar 2017 14:23:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1csZIE-0003Zy-If for bug-gnu-emacs@gnu.org; Mon, 27 Mar 2017 14:23:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49519) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1csZIE-0003Zu-E0 for bug-gnu-emacs@gnu.org; Mon, 27 Mar 2017 14:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1csZIE-0007hb-51 for bug-gnu-emacs@gnu.org; Mon, 27 Mar 2017 14:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Mar 2017 18:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25818 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25818-submit@debbugs.gnu.org id=B25818.149063893029520 (code B ref 25818); Mon, 27 Mar 2017 18:23:02 +0000 Original-Received: (at 25818) by debbugs.gnu.org; 27 Mar 2017 18:22:10 +0000 Original-Received: from localhost ([127.0.0.1]:47718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1csZHN-0007g3-GL for submit@debbugs.gnu.org; Mon, 27 Mar 2017 14:22:09 -0400 Original-Received: from mail-vk0-f46.google.com ([209.85.213.46]:35307) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1csZHL-0007fg-Ek for 25818@debbugs.gnu.org; Mon, 27 Mar 2017 14:22:07 -0400 Original-Received: by mail-vk0-f46.google.com with SMTP id r69so61868637vke.2 for <25818@debbugs.gnu.org>; Mon, 27 Mar 2017 11:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oOh9KSS+Vz5dV0kBXo+kHmumCPMjz/8RJRlofDEvgfY=; b=QaDYdCvtgwM3idTtUGHo74agd+C7M4g2LioccPBkGTJr/9lLft+Cm8AD0Qly2yY/BF YBhzoHPTJ7MMVPAGTW/kDOin2SHn+4umfMoQfhX73aXQ1oFpE6XeNx+P2jS5ii8bZIGj ek/93HOaUcXEF9jEMSZG9FSxZW3sW3zrSqYBUX7wZ2xy+OPNxrVqigncav9ddVUEyZ8R N7DJrQesjwfDQgjd8uJH6oGlMA4wpsMQUnanWnx1BfQXke2w7Cy6k/7o2w5xAiPtXCvG AJrxIw+qVU56lBdTaY65mMvJbgkiOk5tto5K5Z4HMBjjdtyougWUcaSym9BYk+qBS/DS LqyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oOh9KSS+Vz5dV0kBXo+kHmumCPMjz/8RJRlofDEvgfY=; b=nmq6Ho/4QBavDl6c27qTztOafAu5icVtfjZ7xFtkZExbychXr1eDDsFgFjV/IihF+n 1chXe7G1SkL9S9BZkcP2ILQPj+YGHBUAj4uzmzprUdFP0glqcYhvV3XnBNxTWNdjzhRF HxfS5p1B6O0Lx0teOo9X/bwu3GaBjbhjL1sLrRt3bepPdxrmcyeXSPixDwK+w2cJpEn7 CWF9Rnyvb2ji4eSEpkEDMLe4On2iFUUsoX1mtANqCocSduQDhCA74eOpzP41jIRnuA1P U/PV6dSDHTAM4OU6cN+TNODEouAaa7EMC6UP0eF2qsSVvMQtbgNbnqPB+IYudwXTGnfg Ap1g== X-Gm-Message-State: AFeK/H1zzd8Frq3PC3KClMzjvm+6QUWpeRghXO46H3LmwEuqD28i0kSrdrG5BD08Xm3LqZahj27EbXBc2pD/rQ== X-Received: by 10.159.36.169 with SMTP id 38mr8555793uar.115.1490638921816; Mon, 27 Mar 2017 11:22:01 -0700 (PDT) Original-Received: by 10.31.180.11 with HTTP; Mon, 27 Mar 2017 11:22:00 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:131018 Archived-At: --001a113e3c7e6c63b9054bba6b33 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 >=3D 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 =3D [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 =E2=80=9CDisplays ha= ve > separate Spaces=E2=80=9D 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. > --001a113e3c7e6c63b9054bba6b33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!

Sorry for not getting back to you i= mmediately.

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 ba= ck 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 w= ell.)

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

To solve your problem, and to en= sure that we don't break anything for my use case, we would need to cal= l "[super constrainFrameRect:frameRec= t toScreen:screen];" only when the frame is determined to be fully out= side any monitor. This is not rocket science -- just iterate over all monit= ors and check that the frame overlap at least one.

Sincerely,
=C2=A0 =C2=A0 Anders Lindgren

On Sun, Mar 19, 2017 a= t 8:38 PM, Charles A. Roelli <charles@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.=C2=A0 Because from wh= at
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
=C2=A0 =C2=A0 `(set-frame-position (selected-frame) 0 10000)' (best don= e from
=C2=A0 =C2=A0 `emacs -Q').=C2=A0 If the moved frame cannot be returned = on-screen
=C2=A0 =C2=A0 programmatically, then you have the issue.=C2=A0 If it stays = on-screen,
=C2=A0 =C2=A0 then you don't.

My patch got rid of these lines:

-#if MAC_OS_X_VERSION_MAX_ALLOWED >=3D MAC_OS_X_VERSION_10_9
-=C2=A0 // If separate spaces is on, it is like each screen is independent.= =C2=A0 There is
-=C2=A0 // no spanning of frames across screens.
-=C2=A0 if ([NSScreen screensHaveSeparateSpaces])
-=C2=A0 =C2=A0 {
-=C2=A0 =C2=A0 =C2=A0 NSTRACE_MSG ("Screens have separate spaces"= );
-=C2=A0 =C2=A0 =C2=A0 frameRect =3D [super constrainFrameRect:frameRect toS= creen:screen];
-=C2=A0 =C2=A0 =C2=A0 NSTRACE_RETURN_RECT (frameRect);
-=C2=A0 =C2=A0 =C2=A0 return frameRect;
-=C2=A0 =C2=A0 }
-#endif

According to the Apple documentation, screensHaveSeparateSpaces()
"returns a Boolean value that indicates whether each screen can have i= ts
own set of spaces.=C2=A0 This method reflects whether the =E2=80=9CDisplays= have
separate Spaces=E2=80=9D 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?=C2=A0 I assume then, that if you have "Spaces" tu= rned 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.=C2=A0 If it doesn't, then th= e fix
can be added only for OS X < 10.9.

--001a113e3c7e6c63b9054bba6b33--