unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 18637@debbugs.gnu.org
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)	[thread overview]
Message-ID: <ce89167f-4906-496e-9ace-4d51e1741311@default> (raw)
In-Reply-To: <c75b3094-d24b-4949-9c1e-b513c0b5bed7@default>

> > 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 
   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.





  parent reply	other threads:[~2014-10-06 20:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<b5ac6ce3-5c0d-4517-a44f-6925cfccdcfd@default>
     [not found] ` <<837g0dm95c.fsf@gnu.org>
2014-10-06 17:25   ` bug#18637: 24.4.50; doc of frame parameter DISPLAY vs actual value on MS Windows Drew Adams
2014-10-05 19:23     ` Drew Adams
2014-10-05 19:30       ` Eli Zaretskii
2014-10-05 19:44         ` Eli Zaretskii
2014-10-06 18:08       ` Andy Moreton
2014-10-06 18:23         ` Drew Adams
2014-10-07 18:35       ` Andy Moreton
2014-10-07 20:25         ` Drew Adams
2014-10-06 19:29     ` Eli Zaretskii
2014-10-06 20:52     ` Drew Adams [this message]
2014-10-07 15:14       ` Eli Zaretskii
     [not found] <<c75b3094-d24b-4949-9c1e-b513c0b5bed7@default>
     [not found] ` <<ce89167f-4906-496e-9ace-4d51e1741311@default>
     [not found]   ` <<83tx3flxn2.fsf@gnu.org>
2014-10-07 18:12     ` Drew Adams
2014-10-07 18:26       ` Eli Zaretskii
     [not found]     ` <<41484edb-9aaa-4f56-bf46-4ab70b609aac@default>
     [not found]       ` <<8361fvlos0.fsf@gnu.org>
2014-10-07 18:31         ` Drew Adams
     [not found] <<b3d0f532-3b29-43d3-a41d-6687886307dc@default>
     [not found] ` <<83ppe5mfed.fsf@gnu.org>
2014-10-06 16:31   ` Drew Adams
2014-10-06 16:54     ` Eli Zaretskii
     [not found] <<12fc196e-cc82-4f22-8d2f-cede95542ea7@default>
     [not found] ` <<83vbnymi0h.fsf@gnu.org>
     [not found]   ` <<83tx3imhdg.fsf@gnu.org>
2014-10-06  2:55     ` Drew Adams
2014-10-06 14:39       ` Eli Zaretskii
2014-10-06 16:34         ` Stefan Monnier
2014-10-06  2:55   ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ce89167f-4906-496e-9ace-4d51e1741311@default \
    --to=drew.adams@oracle.com \
    --cc=18637@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).