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: Sat, 29 Apr 2017 19:23:14 +0200 Message-ID: References: <58AEA232.4000708@gmx.at> <58B30634.1090904@gmx.at> <58B3DDBA.6060003@gmx.at> <59046B35.1010808@gmx.at> <39f502e9-7b31-a250-c964-8977689cad9b@aurox.ch> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c12334402910e054e51726d X-Trace: blaine.gmane.org 1493486661 31446 195.159.176.226 (29 Apr 2017 17:24:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Apr 2017 17:24:21 +0000 (UTC) Cc: Alan Third , 25818@debbugs.gnu.org To: "Charles A. Roelli" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 29 19:24:12 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 1d4W6L-0007tk-EC for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Apr 2017 19:24:09 +0200 Original-Received: from localhost ([::1]:41827 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d4W6O-0007cS-5t for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Apr 2017 13:24:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d4W6H-0007cM-Eh for bug-gnu-emacs@gnu.org; Sat, 29 Apr 2017 13:24:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d4W6E-00038d-8z for bug-gnu-emacs@gnu.org; Sat, 29 Apr 2017 13:24:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48370) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d4W6E-00038Y-3K for bug-gnu-emacs@gnu.org; Sat, 29 Apr 2017 13:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1d4W6D-0007iO-Uw for bug-gnu-emacs@gnu.org; Sat, 29 Apr 2017 13:24:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Apr 2017 17:24:01 +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.149348660329589 (code B ref 25818); Sat, 29 Apr 2017 17:24:01 +0000 Original-Received: (at 25818) by debbugs.gnu.org; 29 Apr 2017 17:23:23 +0000 Original-Received: from localhost ([127.0.0.1]:46559 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d4W5b-0007hB-0D for submit@debbugs.gnu.org; Sat, 29 Apr 2017 13:23:23 -0400 Original-Received: from mail-ua0-f178.google.com ([209.85.217.178]:34189) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d4W5Z-0007gy-7n for 25818@debbugs.gnu.org; Sat, 29 Apr 2017 13:23:22 -0400 Original-Received: by mail-ua0-f178.google.com with SMTP id q26so15263249uaa.1 for <25818@debbugs.gnu.org>; Sat, 29 Apr 2017 10:23:21 -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=VsW+R15eWDaOKIS38XFJU+R7VA8Ko3HQWFNI3d5a3jY=; b=P49Y9xSX2zFhniYaikemyLdzrAUVHnBanlrGe3j4zBVTEZAHDPJIV168pFBWC6BjlO kNNkuma+XWgyZtvhN8mRF7wpbi0VWUkGx/AFuaXUGcBmJzWlX7n5LgCfykXmGuUWM0cL 8hWGkFFudU0PyOXyuKL+1AKhYdMtsATUx6zvDFpas6kFjLeuLUH/2eT/1MXh11mVr6/a 5h+pLYP3x7Qz1iiOx6se9SSQ23GwEcBAXl7PhjDL/YEhmSHI7Jp2COod/SQ9Op8uje67 1/7trzJXFFu1nsk4oHCn5koDiChBkaQWdQAKWNSwYS0JPuzpl4DcLErbtxfNklElbSqh OAQQ== 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=VsW+R15eWDaOKIS38XFJU+R7VA8Ko3HQWFNI3d5a3jY=; b=pMRad8B0BIrN/S2grbVIg9Wx0ZJwz8CutKrqGWCwNQaSh/h4Ev34x6P3B0QraeMclw ko/wbaHGoKKVm1R1ZFCPzWXybIje+dGfhvDqc/S31djO8DBIUp+ErGcfjZuXnsxQQEeH qe9f5JASdBk/XzG2mOs94qXXKambw7Z9NrbBg1Ijpnn2EnIjv0QSWKnod1qzmXgf0cJV LFf7307Uja7ke4PNrnTutqRdett5TO6Kin4KDcreZJ0jFyCNNxILLz4lQp+eNgIyfe0Z 5DJSqgW99voNwMH2GjB3afzy0NPxXteM4O45/BjfuKgvrrx13ACtUP7MNCJ+sCLyyik5 LdOA== X-Gm-Message-State: AN3rC/43wPCzByjA1KIn68PFUx3ml676YCSz/+1cigBadZdOt5mRjAcY qWxAG6KULpkoSrBVnqtBLPcxVh0S6g== X-Received: by 10.159.39.196 with SMTP id b62mr9131339uab.108.1493486595639; Sat, 29 Apr 2017 10:23:15 -0700 (PDT) Original-Received: by 10.31.64.140 with HTTP; Sat, 29 Apr 2017 10:23:14 -0700 (PDT) In-Reply-To: <39f502e9-7b31-a250-c964-8977689cad9b@aurox.ch> 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:132108 Archived-At: --94eb2c12334402910e054e51726d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! If I understand correctly, when the menu bar is visible, macOS will force any window down below it. It's not something one can do about it, as far as I know. However, when the menu bar is hidden, or on secondary monitors (i.e. one that don't have a menu bar), a window can be placed above the top programmatically (but it's not possible for a user to drag it there). The reason the Emacs code checks if spaces are enabled is historical. The original NS code in Emacs 23 didn't support stretching a frame across two monitors (whereas Emacs 22 supported this). When this was fixed for Emacs 23 the maintainer of the time, Jan Dj=C3=A4rv, decided to retain the origin= al behaviour when spaces are enabled (since a frame can't be stretched across multiple monitors). Maybe this is something we could revisit now. (One thing I'm curious about is if it is possible to hide the menu bar and place the frame above the top of the display, if spaces are enabled -- I suspect that it's not possible but I haven't tested.) -- Anders On Sat, Apr 29, 2017 at 1:15 PM, Charles A. Roelli wrote= : > With the current master branch, a child frame might be constrained on OS = X > 10.9+ with the "Spaces" windowing feature turned on, meaning that a child > frame could be forced back into the screen area -- so yes, there could be= a > case where a child frame doesn't move together with its parent. Maybe th= at > will have to be fixed too; I'm on 10.6 though so I can't test. > > Otherwise, though, when child/parent frames are not brought off screen, a > child frame always moves with its parent. > > My updated patch takes into account the case where "Spaces" is off or > unavailable -- if you read the part above what I added: > > #ifdef NS_IMPL_COCOA > #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 > > there is nothing there to prevent a child frame from being constrained -- > so I will need input from somebody else on that. > > > > On 29/04/2017 12:30, martin rudalics wrote: > >> > I fixed the patch so that child frames are never constrained (after >> > some testing, it seems that a child frame cannot get stuck off screen >> > as long as its parent is still visible). To test this out, evaluate >> > the following from emacs -Q, >> > >> > (progn >> > (setq test-frame (make-frame `((parent-frame . ,(selected-frame))))= ) >> > (set-frame-position test-frame 0 500)) >> > >> > and drag the parent frame down until its child is off screen. >> >> Does this mean that the child frame does _not_ move together with its >> parent frame? That would constitute a major deviation from the other >> platforms. >> >> martin >> > > --94eb2c12334402910e054e51726d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!

If I understand correctly, when the= menu bar is visible, macOS will force any window down below it. It's n= ot something one can do about it, as far as I know.

However, when the menu bar is hidden, or on secondary monitors (i.e. one = that don't have a menu bar), a window can be placed above the top progr= ammatically (but it's not possible for a user to drag it there).
<= div>
The reason the Emacs code checks if spaces are enabled i= s historical. The original NS code in Emacs 23 didn't support stretchin= g a frame across two monitors (whereas Emacs 22 supported this). When this = was fixed for Emacs 23 the maintainer of the time, Jan Dj=C3=A4rv, decided = to retain the original behaviour when spaces are enabled (since a frame can= 't be stretched across multiple monitors). Maybe this is something we c= ould revisit now. (One thing I'm curious about is if it is possible to = hide the menu bar and place the frame above the top of the display, if spac= es are enabled -- I suspect that it's not possible but I haven't te= sted.)

=C2=A0 =C2=A0 -- Anders

On Sat, Apr 29, 2017 at 1= :15 PM, Charles A. Roelli <charles@aurox.ch> wrote:
With the current master branch, a child frame migh= t be constrained on OS X 10.9+ with the "Spaces" windowing featur= e turned on, meaning that a child frame could be forced back into the scree= n area -- so yes, there could be a case where a child frame doesn't mov= e together with its parent.=C2=A0 Maybe that will have to be fixed too; I&#= 39;m on 10.6 though so I can't test.

Otherwise, though, when child/parent frames are not brought off screen, a c= hild frame always moves with its parent.

My updated patch takes into account the case where "Spaces" is of= f or unavailable -- if you read the part above what I added:

#ifdef NS_IMPL_COCOA
#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 toSc= reen:screen];
 =C2=A0 =C2=A0 =C2=A0 NSTRACE_RETURN_RECT (frameRect);
=C2=A0 =C2=A0 =C2=A0 return frameRect;
=C2=A0 =C2=A0 }
#endif

there is nothing there to prevent a child frame from being constrained -- s= o I will need input from somebody else on that.



On 29/04/2017 12:30, martin rudalics wrote:
> I fixed the patch so that child frames are never constrained (after > some testing, it seems that a child frame cannot get stuck off screen<= br> > as long as its parent is still visible).=C2=A0 To test this out, evalu= ate
> the following from emacs -Q,
>
> (progn
>=C2=A0 =C2=A0 (setq test-frame (make-frame `((parent-frame . ,(selected= -frame)))))
>=C2=A0 =C2=A0 (set-frame-position test-frame 0 500))
>
> and drag the parent frame down until its child is off screen.

Does this mean that the child frame does _not_ move together with its
parent frame?=C2=A0 That would constitute a major deviation from the other<= br> platforms.

martin


--94eb2c12334402910e054e51726d--