From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Andy Moreton Newsgroups: gmane.emacs.bugs Subject: bug#34516: Multi-monitor frame sets Date: Sat, 02 Mar 2019 23:57:35 +0000 Message-ID: <86r2bosuc0.fsf@gmail.com> References: <87bm3a74s4.fsf@mail.linkov.net> <87zhqsx115.fsf@mail.linkov.net> <87r2byw802.fsf@mail.linkov.net> <20190302205424.GB20712@breton.holly.idiocy.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="11681"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (windows-nt) To: 34516@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Mar 03 00:58:11 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h0EWB-0002vK-8X for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 Mar 2019 00:58:11 +0100 Original-Received: from localhost ([127.0.0.1]:60347 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h0EWA-0001yn-9G for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Mar 2019 18:58:10 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h0EW3-0001yR-4Z for bug-gnu-emacs@gnu.org; Sat, 02 Mar 2019 18:58:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h0EW2-0004hm-8L for bug-gnu-emacs@gnu.org; Sat, 02 Mar 2019 18:58:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44415) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h0EW2-0004hc-54 for bug-gnu-emacs@gnu.org; Sat, 02 Mar 2019 18:58:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1h0EW1-0007pb-VH for bug-gnu-emacs@gnu.org; Sat, 02 Mar 2019 18:58:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: <87bm3a74s4.fsf@mail.linkov.net> Resent-From: Andy Moreton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Mar 2019 23:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34516 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.155157107530091 (code B ref -1); Sat, 02 Mar 2019 23:58:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 2 Mar 2019 23:57:55 +0000 Original-Received: from localhost ([127.0.0.1]:57959 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0EVv-0007pH-59 for submit@debbugs.gnu.org; Sat, 02 Mar 2019 18:57:55 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35728) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h0EVs-0007p4-VK for submit@debbugs.gnu.org; Sat, 02 Mar 2019 18:57:53 -0500 Original-Received: from lists.gnu.org ([209.51.188.17]:42981) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h0EVn-0004MT-Ju for submit@debbugs.gnu.org; Sat, 02 Mar 2019 18:57:47 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h0EVm-0001vy-Fs for bug-gnu-emacs@gnu.org; Sat, 02 Mar 2019 18:57:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h0EVl-0004IM-GD for bug-gnu-emacs@gnu.org; Sat, 02 Mar 2019 18:57:46 -0500 Original-Received: from [195.159.176.226] (port=55328 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h0EVl-0004EH-4y for bug-gnu-emacs@gnu.org; Sat, 02 Mar 2019 18:57:45 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1h0EVj-0002Hv-2D for bug-gnu-emacs@gnu.org; Sun, 03 Mar 2019 00:57:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:SvhbTlGyIzu63Uiuhamhr7QyJ78= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x 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: 209.51.188.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:155980 Archived-At: On Sat 02 Mar 2019, Alan Third wrote: > On Sun, Feb 24, 2019 at 01:56:31PM +0100, Robert Pluim wrote: >> Juri Linkov writes: >> >> > Since on Windows 'display-monitor-attributes-list' returns such >> > fake monitor names: >> > >> > \\.\DISPLAY1 >> > \\.\DISPLAY2 These names are *not* fake: they are the name of the underlying device that represents the monitor. >> > on macOS it could return something like that or generate fake names >> > from geometry like "1920x1080+0+0", "2560x1440+1920+16". It would be more usefulr to use the underlying device name, like on other platforms. > I’m a bit late to this conversation, sorry. > > I’d hope that the geometry would contain the origin of the monitor in > the overall screen ‘space’, so the primary monitor would have 0, 0, > and one to the left would have -1920, 0, or something. So it might not > be too confusing. Yes, that is exactly how it works: the geometry shows where the monitor is positioned in the overall coordinate system, and the workspace shows the area on that monitor that is available to display frames (i.e. not occupied by system tray toolbar, dock etc). >> Something like this (assuming nobody every connects more than 9 >> monitors to the same system). Not a sound assumption: why add an arbitrary limitation when there is no need to ? Allow an arbitrary number of monitors, since there is no reason to restrict it. >> >> diff --git a/src/nsfns.m b/src/nsfns.m >> index edcdb988f7..91ab17032c 100644 >> --- a/src/nsfns.m >> +++ b/src/nsfns.m >> @@ -2698,6 +2698,12 @@ and GNUstep implementations ("distributor-specific release >> >> #ifdef NS_IMPL_COCOA >> m->name = ns_screen_name (did); >> + if (m->name == NULL) /* Fallback value. */ >> + { >> + char name[9]; >> + snprintf (name, sizeof(name), "DISPLAY%1d", i+1); >> + m->name = xstrdup (name); >> + } >> >> { >> CGSize mms = CGDisplayScreenSize (did); > > This appears to be the only place that ns_screen_name is called, so it > would probably be better to put this code in it and make > ns_screen_name return a name no matter what. > > Also, it might be worth considering using the ‘did’ value instead of > ‘i’. As far as I can tell it’s just a uint32_t, and should stay the > same as long as the system isn’t rebooted. Is the did value reused if monitors are dynamically plugged and unplugged ? This may happen when using a laptop with docking stations and external monitors. AndyM