From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Date: Mon, 6 Oct 2014 13:52:17 -0700 (PDT) Message-ID: References: <> <<837g0dm95c.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1412628810 21546 80.91.229.3 (6 Oct 2014 20:53:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Oct 2014 20:53:30 +0000 (UTC) Cc: 18637@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 06 22:53:21 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XbFHV-0006vi-Gs for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Oct 2014 22:53:21 +0200 Original-Received: from localhost ([::1]:54342 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbFHV-0005zZ-7P for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Oct 2014 16:53:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbFHK-0005zO-Ma for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2014 16:53:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbFHD-0003gW-27 for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2014 16:53:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44462) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbFHC-0003gP-Vz for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2014 16:53:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XbFHC-0005hg-3i for bug-gnu-emacs@gnu.org; Mon, 06 Oct 2014 16:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Oct 2014 20:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18637-submit@debbugs.gnu.org id=B18637.141262874921874 (code B ref 18637); Mon, 06 Oct 2014 20:53:02 +0000 Original-Received: (at 18637) by debbugs.gnu.org; 6 Oct 2014 20:52:29 +0000 Original-Received: from localhost ([127.0.0.1]:36026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbFGe-0005gh-Hc for submit@debbugs.gnu.org; Mon, 06 Oct 2014 16:52:29 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:38193) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbFGa-0005gW-Gn for 18637@debbugs.gnu.org; Mon, 06 Oct 2014 16:52:25 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s96KqK9k030354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Oct 2014 20:52:22 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s96KqJWh004753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Oct 2014 20:52:19 GMT Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s96KqJSR004740; Mon, 6 Oct 2014 20:52:19 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:94216 Archived-At: > > Read it and its sections. You will find the information you want > > there. Skip whatever sounds not relevant or too low-level, and > > keep reading. Read the MSDN documentation I pointed to, the answers > > are there. I read it all. The closest thing I noticed as relevant to my question was the 2 bits below, in Multiple Display Monitors > About Multiple Display Monitors > Positioning Objects on Multiple Display Monitors: 1. CreateWindow(Ex) displays a window on the monitor that contains the largest part of the window. Maximizes on the monitor that contains the largest part of the window before it was minimized. I gather from that that perhaps the problem is that a larger portion of the displayed frame might be on the other monitor, in which case the frame gets displayed (only?) on the other monitor. I guess that would mean that frame-position coordinates (`left', `top') are then interpreted relative to that other monitor (?). Is that right? 2. To position an object on a multiple monitor system 1. Determine the appropriate monitor. 2. Get the coordinates to the monitor. 3. Position the object using the coordinates. This suggests that the position of the desired (target) monitor needs to be added to the frame position, to get it to be on the intended monitor. Was that your point? Here is what I guess I still do not understand. Are the values of `left' etc. frame parameters relative to just the virtual display (which is the envelope of all of the monitors, at least on Windows)? In that case they would be essentially absolute and not depend on which monitor the frame is shown in. That is what I would expect, from the fact that Emacs just "sees a single large desktop", as Stefan put it. But if that were the case then I would think that restoring a recorded `left' etc. parameter later would put the frame back where it was, which is apparently not what is happening. On the other hand, if `left' etc. are relative to the monitor in which the frame is shown then I guess my code would need to add the monitor position and size, to give coordinates that are absolute (i.e., relative to the virtual display, aka "desktop"). The Windows doc you pointed to also says that the primary monitor is not necessarily at the left. So if `left' etc were not absolute but relative to the monitor origin then maybe this is what happened: 1. The OP had a frame in the left monitor, but the right monitor was primary. Since the primary monitor has the virtual screen's origin at its top left, positions in the left monitor would have negative horizontal positions. Dunno whether that means they should also have negative `left' positions, for Emacs. If `left' etc. are relative to the virtual=20 screen then yes, they would. If `left' etc. is relative to the current monitor then no, they would not. 2. My maximize/restore code stored the values of `left' etc. for later restore/maximize, but if these values are relative to the current monitor, when restored they might be interpreted as relative to the primary monitor (since no monitor is specified). So the frame would jump to the monitor on the right. Is that possible? If so, why wouldn't the monitor for the frame remain the same? What determines which monitor gets used? > > If, after that, you still don't understand what could go wrong > > with your code, come back and ask more specific questions with specific > > code snippets. Right now, what you write and ask just shows how > > much of the background you are missing to start reasoning about > > this. > > > > The issues are not complicated once you understand how Windows > > treats multiple monitors. Hopefully you can see from the above a little more clearly what I still misunderstand. And hopefully you will be able to help me understand a bit better. The relevant code snippet is what I sent earlier (`frcmds-available-screen-pixel-bounds'), plus functions `maximize-frame' and `restore-frame', here: http://www.emacswiki.org/emacs-en/download/frame-cmds.el In those two commands I do the following. For `maximize-frame': 1. Save the current `left' etc. as parameters `restore-left' etc. 2. Calculate the available screen size, using `frcmds-available-screen-pixel-bounds'. 3. Set `left' and `top' both to 0 and `width' and `height' to the calculated screen size. For `restore-frame': Restore `left' etc. from the saved values `restore-left' etc.