bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 6 Oct 2014 13:52:17 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 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.