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: Tue, 28 Feb 2017 21:35:15 +0100 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=001a114e61bc35dcda05499d2261 X-Trace: blaine.gmane.org 1488314178 6832 195.159.176.226 (28 Feb 2017 20:36:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Feb 2017 20:36:18 +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 Tue Feb 28 21:36: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 1cioVF-00013v-NO for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Feb 2017 21:36:09 +0100 Original-Received: from localhost ([::1]:36717 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cioVL-00051U-Nk for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Feb 2017 15:36:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cioVD-0004ys-1q for bug-gnu-emacs@gnu.org; Tue, 28 Feb 2017 15:36:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cioV9-00073a-Sf for bug-gnu-emacs@gnu.org; Tue, 28 Feb 2017 15:36:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34166) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cioV9-00073R-OA for bug-gnu-emacs@gnu.org; Tue, 28 Feb 2017 15:36:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cioV8-00046Z-2V for bug-gnu-emacs@gnu.org; Tue, 28 Feb 2017 15:36:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Feb 2017 20:36: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.148831412915725 (code B ref 25818); Tue, 28 Feb 2017 20:36:02 +0000 Original-Received: (at 25818) by debbugs.gnu.org; 28 Feb 2017 20:35:29 +0000 Original-Received: from localhost ([127.0.0.1]:60598 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cioUb-00045Y-0x for submit@debbugs.gnu.org; Tue, 28 Feb 2017 15:35:29 -0500 Original-Received: from mail-ua0-f170.google.com ([209.85.217.170]:33288) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cioUY-00045L-SS for 25818@debbugs.gnu.org; Tue, 28 Feb 2017 15:35:27 -0500 Original-Received: by mail-ua0-f170.google.com with SMTP id x24so27165570uab.0 for <25818@debbugs.gnu.org>; Tue, 28 Feb 2017 12:35:26 -0800 (PST) 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=u4mf07Ee00VgXkDPZfNO6mXWn+OwB2LRL1pxzmXLcmg=; b=otoPagZGPimjC8C1XgfA7/76Nryn9DLIFh7hOGPES0k2rHyPFhF2W/2tXkFevnEwkL 7Yqq+FCEwsQaM4kG5l2dOUujIMeQ6Z6Jl3sq68eXDpCySti2bTIyIfRvCnB9zJd0XzG4 ZzanH814F6mcaYQT6CUfQPRywLyTSCVSSge88EyOr7QZCUxTKyn7pVRvaNtDlyHIN63A 2S+cts+PnG9R/C6kM7a1UDhEAQjpvxF2Lo1XJKaVxedoPQCYz43cbLZOUPLSPfvq9LqH NzO+X9QZE8t6CG5PXLaoyZ2U+VDw/YslGUTQnoa/JBHdrFB61uWlbhpZVtxoMDP1nLZS BynA== 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=u4mf07Ee00VgXkDPZfNO6mXWn+OwB2LRL1pxzmXLcmg=; b=qkJYS/bTSGwBT9mRvsSlGPevM4/AmghYxi0+pwWmQ9kT6mGLUicvrVGBmld3E45s6r OvaCq4M6eRz7osGbodpXP147+o3vEmt7K9iwMZLX3OTpO5bkvekxV14d1zjQrROnDRna DUIOMTQkn9hFmFsGOmCvbLz31BhCdW+OrCGKmUQ+/yDygf6/pEj/+5ldBFuMpPB4k4cP bKy0HNhwqwj1PHy4xOXkXaIYEuXyfs+oE1P30yLVeap61wJIMP3UDeJUbRC85lZtIUVp brbsj/kIIan1+Gic19ohCdXsDceTqYWES3Cq5mp7zyFlhl5GYKTQqbMX348UTSCr6N0E X3VA== X-Gm-Message-State: AMke39nRq/k+di8+GrhQIbwBJQCL12B5BPAp35EAF8b10NlfP0nbFD8pWs7BglUsOuOt2f3eTiENuUkexjl0hg== X-Received: by 10.31.96.20 with SMTP id u20mr2009572vkb.53.1488314116199; Tue, 28 Feb 2017 12:35:16 -0800 (PST) Original-Received: by 10.31.242.15 with HTTP; Tue, 28 Feb 2017 12:35:15 -0800 (PST) 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:129959 Archived-At: --001a114e61bc35dcda05499d2261 Content-Type: text/plain; charset=UTF-8 Hi! > I've tested my patched version of Emacs master and I can stretch one > frame across both screens (seemingly) without any problem. It is > possible that my patched version would not do the right thing on OS X > 10.9+, though, if the interaction with "Spaces" and constrainFrameRect > is different there. > > [BTW, if I understand right, "Spaces" in Mac OS X 10.9+ prevent you from > having any frame spanning multiple monitors. Does the current Emacs > code (without my patch) remove that limitation?] > In 10.9, a "space" is a dedicated full-frame area. I don't think your patch will affect this. It took quite a lot of work to get the current implementation to work for a variety of scenarios. To throw in a "quick fix" for another scenario will most likely break things that work today. It would be better to identify some situations when the function should behave differently and fix those specific cases. > A better solution would be to add to code to check if the Emacs frame is > > outside any monitor, and then (and only then) call the constrainFrameRect > > method of the parent class. > > Your use case above for a frame (placing it above the top of the screen, > as with `(set-frame-position (selected-frame) 0 -10)' in your test > code), would (I think) count as bringing the frame outside of a screen, > and therefore constrainFrameRect would kick in, bringing the frame back > to ((top . 0) (left . 0)) -- as my patched version does. But this is > apparently not what you want. So we would need to allow some leeway in > the calculation to allow a frame to be only slightly outside of a > monitor? This sounds complicated to me. > I think it is acceptable if a frame is partially outside the display. What I suggested was to check if the frame was ENTIRELY outside any monitor, and in that case call the parent function to bring it in. This test should be trivial to implement. You can find a lot of the recent design decisions of the NS port in the epic discussion thread of bug 21415. Also, thank you for pointing out `ns-auto-hide-menu-bar'. I did not > know about that variable. But I do not understand why you would want to > place a frame above the top of the screen when the menu bar is hidden. > It might give you an extra row of text, at the cost of obscuring the > close/iconify/maximize buttons, and the frame title. You could get more > bang for your buck by turning off `tool-bar-mode', IMO. And I don't > think OS X natively allows a user to place a frame above the top of the > screen anyway. > By placing the title bar above the top of the screen, I'm able to use the entire height of the monitor for text, while having access to the menu by moving the mouse pointer to the top of the screen. I don't need the buttons and the frame title is of little use. Admittedly, I'm a bit crazy when it comes to screen real estate -- with a small font, six side-by-side windows, and Follow mode enabled, I get 888 consecutive lines of text. > Anyway, I'm glad that you have looked into this. The number of people > > actively working on the NS port are close to zero (I threw in the towel > > about a year ago, simply because I couldn't find the time I needed to > spend > > on it). If you are interested in contributing, you can look at the > > "NeXTstep port" section of the "TODO" file. > > Will do. Do you know of any good resources for tinkering in this area? > I have some old Apple docsets available which I haven't really gotten > around to reading yet, but that's about it. I mostly look at the reference documentation like https://developer.apple.com/reference/appkit/nswindow There are tons of introductory text on macOS (which, internally, is similar for iOS). You have to look for one which suit your background knowledge. You can, however, skip anything related to the "Interface Builder", since it's not used by Emacs. If you don't know Objective-C, I would recommend you to start with an introduction to that, and go from there. -- Anders --001a114e61bc35dcda05499d2261 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!
=C2=A0
I'= ;ve tested my patched version of Emacs master and I can stretch one
frame across both screens (seemingly) without any problem.=C2=A0 It is
possible that my patched version would not do the right thing on OS X
10.9+, though, if the interaction with "Spaces" and constrainFram= eRect
is different there.

[BTW, if I understand right, "Spaces" in Mac OS X 10.9+ prevent y= ou from
having any frame spanning multiple monitors.=C2=A0 Does the current Emacs code (without my patch) remove that limitation?]

<= /div>
In 10.9, a "space" is a dedicated full-frame area. I do= n't think your patch will affect this.

It took= quite a lot of work to get the current implementation to work for a variet= y of scenarios. To throw in a "quick fix" for another scenario wi= ll most likely break things that work today. It would be better to identify= some situations when the function should behave differently and fix those = specific cases.


> A better solution would be to add to = code to check if the Emacs frame is
> outside any monitor, and then (= and only then) call the constrainFrameRect
> method of the parent cla= ss.

Your use case above for a frame (placing it above the top of the= screen,
as with `(set-frame-position (selected-frame) 0 -10)' in yo= ur test
code), would (I think) count as bringing the frame outside of a = screen,
and therefore constrainFrameRect would kick in, bringing the fra= me back
to ((top . 0) (left . 0)) -- as my patched version does.=C2=A0 B= ut this is
apparently not what you want.=C2=A0 So we would need to allow= some leeway in
the calculation to allow a frame to be only slightly out= side of a
monitor?=C2=A0 This sounds complicated to me.
=

I think it is acceptable if a frame is partially outsid= e the display. What I suggested was to check if the frame was ENTIRELY outs= ide any monitor, and in that case call the parent function to bring it in. = This test should be trivial to implement.

Yo= u can find a lot of the recent design decisions of the NS port in the epic = discussion thread of bug 21415.


Also, thank you for pointing out = `ns-auto-hide-menu-bar'.=C2=A0 I did not
know about that variable.=C2=A0 But I do not understand why you would want = to
place a frame above the top of the screen when the menu bar is hidden.
It might give you an extra row of text, at the cost of obscuring the
close/iconify/maximize buttons, and the frame title.=C2=A0 You could get mo= re
bang for your buck by turning off `tool-bar-mode', IMO.=C2=A0 And I don= 't
think OS X natively allows a user to place a frame above the top of the
screen anyway.

By placing the title bar= above the top of the screen, I'm able to use the entire height of the = monitor for text, while having access to the menu by moving the mouse point= er to the top of the screen. I don't need the buttons and the frame tit= le is of little use.

Admittedly, I'm a bit cra= zy when it comes to screen real estate -- with a small font, six side-by-si= de windows, and Follow mode enabled, I get 888 consecutive lines of text.


> Anyway, I'm glad that you have looked into this. = The number of people
> actively working on the NS port are close to zero (I threw in the towe= l
> about a year ago, simply because I couldn't find the time I needed= to spend
> on it). If you are interested in contributing, you can look at the
> "NeXTstep port" section of the "TODO" file.

Will do.=C2=A0 Do you know of any good resources for tinkering in th= is area?
I have some old Apple docsets available which I haven't really gotten around to reading yet, but that's about it.

=
I mostly look at the reference documentation like https://dev= eloper.apple.com/reference/appkit/nswindow

There are tons of introductory text on macOS (which, internally, is simil= ar for iOS). You have to look for one which suit your background knowledge.= You can, however, skip anything related to the "Interface Builder&quo= t;, since it's not used by Emacs. If you don't know Objective-C, I = would recommend you to start with an introduction to that, and go from ther= e.

=C2=A0 =C2=A0 -- Anders

--001a114e61bc35dcda05499d2261--