From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Date: Tue, 07 Oct 2014 18:14:57 +0300 Message-ID: <83tx3flxn2.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1412694925 24668 80.91.229.3 (7 Oct 2014 15:15:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Oct 2014 15:15:25 +0000 (UTC) Cc: 18637@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 07 17:15:19 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 1XbWTr-0000N7-O8 for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Oct 2014 17:15:15 +0200 Original-Received: from localhost ([::1]:59370 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbWTr-00078o-Ai for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Oct 2014 11:15:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51121) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbWTj-0006zn-Ri for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2014 11:15:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbWTe-0006gR-VT for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2014 11:15:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45224) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbWTe-0006gH-Sn for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2014 11:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XbWTd-0004FY-P5 for bug-gnu-emacs@gnu.org; Tue, 07 Oct 2014 11:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Oct 2014 15:15:01 +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.141269489416303 (code B ref 18637); Tue, 07 Oct 2014 15:15:01 +0000 Original-Received: (at 18637) by debbugs.gnu.org; 7 Oct 2014 15:14:54 +0000 Original-Received: from localhost ([127.0.0.1]:36788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbWTV-0004Es-3W for submit@debbugs.gnu.org; Tue, 07 Oct 2014 11:14:53 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:52695) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XbWTQ-0004Ed-3g for 18637@debbugs.gnu.org; Tue, 07 Oct 2014 11:14:51 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0ND200300YBDCC00@a-mtaout22.012.net.il> for 18637@debbugs.gnu.org; Tue, 07 Oct 2014 18:14:46 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ND2003ADYCMCA00@a-mtaout22.012.net.il>; Tue, 07 Oct 2014 18:14:46 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il 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:94237 Archived-At: > Date: Mon, 6 Oct 2014 13:52:17 -0700 (PDT) > From: Drew Adams > Cc: 18637@debbugs.gnu.org > > 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. That's my understanding as well, but someone who has access to such a system should actually try that and report back. > I guess that would mean that frame-position coordinates (`left', > `top') are then interpreted relative to that other monitor (?). Is > that right? No, I think they are "ignored". That is, the coordinates are interpreted in the virtual coordinate system, but then Windows decides on its own how to position the frame, using the criterion described above. > 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. But I think this is not enough: you need also make sure the size of the frame is such as to cause Windows decide to actually place the frame on that monitor. Because if the size is such that the largest portion of the window is on another monitor, you won't get what you want. Again, something to play with and report. > 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)? Yes, according to my reading of the code and the MSDN documentation. But again, actually trying that will bring a much more reliable information. > 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. Except that Windows has its own rules, see above, at least when you create a frame that didn't exist (i.e. restore it from information recorded in some file). > 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 > screen then yes, they would. If `left' etc. is relative to the > current monitor then no, they would not. Again, my understanding is that they are relative to the visrtual coordinate system. > 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. That's a lot of code, and I have no way of trying it. I think at this stage it is best for the user in question to try some simple code that reports frame coordinates and creates a frame given specific coordinates, and then see what that means for us. Oh, and I think this is no longer about the docs, so probably a new bug report is in order, specifically about restoring frames on multi-monitor displays.