GNU bug report logs - #18657
24.4.50; positioning frames on multi-monitor displays

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18657 in the body.
You can then email your comments to 18657 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; positioning frames on multi-monitor displays
Date: Tue, 7 Oct 2014 11:29:29 -0700 (PDT)

This is a followup to the thread for bug #18637.  Please see that
thread.

It's not clear to me how to understand/calculate which monitor a given
frame will be displayed on, or how (if at all possible) to control which
monitor is used.

What the code in question does is to (a) save the original `left',
`top', `width', and `height' frame parameter values for a frame, and
then to change those, using `modify-frame-parameters', to resize the
frame to a "maximized" size (in quotes because the size does not
necessarily correspond exactly to what maximize might mean for the
window manager, and window-manager maximization is not employed).

The "restore" part of the code then calls `modify-frame-parameters'
to set the `left' etc. parameters back to the saved (original) values.
(The values are saved in new frame paramters, `restore-left', etc.)

The code does not delete or create any frames.  It just sets those frame
parameters.  The problem encountered is that the monitor in which the
frame is displayed changes.  The aim is to keep the frame on the same
monitor, regardless of the size change.

The OP reporting the problem is not, I think, on MS Windows, but I test
the code only on Windows.  The problem reported is likely on more than
one platform.  I would be interested in a platform-independent solution.

The code in question is commands `maximize-frame' and `restore-frame' in
this library: http://www.emacswiki.org/emacs-en/download/frame-cmds.el.
This other library is required by that one, in general:
http://www.emacswiki.org/emacs-en/download/frame-fns.el.


In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-09-15 on LEG570
Bzr revision: 117884 dancol <at> dancol.org-20140915050944-sqsajysnwef51f9m
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

Message #8 received at 18657 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: 18657 <at> debbugs.gnu.org
Subject: RE: bug#18657: 24.4.50; positioning frames on multi-monitor displays
Date: Tue, 7 Oct 2014 14:18:13 -0700 (PDT)

As an update, the OP who reported the issue to me confirms that he
is using MS Windows (I thought he was not).  And he sent me this
info from his setup:

(frame-parameters):

((tool-bar-position . top) (parent-id) (explicit-name) (display . "w32") (visibility . t) (icon-name) (window-id . "459396") (top . 11) (left + -1249) (buried-buffer-list) (buffer-list #<buffer *Messages*> #<buffer  *Minibuf-1*> #<buffer procedure-codes.org> #<buffer  *Agenda Commands*> #<buffer *Org Agenda(w)*> #<buffer work-log.org>) (unsplittable) ...

M-x maximize-frame

(frame-parameters):
((tool-bar-position . top) (parent-id) (explicit-name) (display . "w32") (visibility . t) (icon-name) (window-id . "459396") (top . 0) (left . 0) (buried-buffer-list) (buffer-list #<buffer *Messages*> #<buffer  *Minibuf-1*> #<buffer procedure-codes.org> #<buffer  *Agenda Commands*> #<buffer *Org Agenda(w)*> #<buffer work-log.org>) (unsplittable) ...)
M-x restore-frame
((tool-bar-position . top) (parent-id) (explicit-name) (display . "w32") (visibility . t) (icon-name) (window-id . "459396") (top . 11) (left + -1249) (buried-buffer-list) (buffer-list #<buffer *Messages*> #<buffer  *Minibuf-1*> #<buffer procedure-codes.org> #<buffer  *Agenda Commands*> #<buffer *Org Agenda(w)*> #<buffer work-log.org>) (unsplittable) ...)

Based on that, I've sent him an updated version of `maximize-frame'
(from `frame-cmds.el'), which differs only in not using (0,0) as the
position coordinates systematically.  Instead, it uses this:

(nth 1 (assq 'workarea (frame-monitor-attributes frame))) ; For left
(nth 2 (assq 'workarea (frame-monitor-attributes frame))) ; For right

Andy, perhaps you could try that?

[I'm assuming that the `workarea' and `geometry' values are, in order:
LEFT TOP, WIDTH HEIGHT.

FWIW, The doc of `display-monitor-attributes-list' refers to them as
X Y WIDTH HEIGHT, and the doc of `frame-monitor-attributes' refers to
the `d-m-a-l' doc.  Not so clear (What are X and Y? What units for
WIDTH and HEIGHT?), but better than nothing.

(BTW, if these essentially follow the `geometry' X Window spec, why
is the order changed from what is used for that?)]

Message #11 received at 18657 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: 18657 <at> debbugs.gnu.org
Subject: RE: bug#18657: 24.4.50; positioning frames on multi-monitor displays
Date: Tue, 7 Oct 2014 16:56:40 -0700 (PDT)

FYI - The OP tried this code that I suggested, for left and top,
instead of 0 and 0, in the `maximize-frame' code of frame-cmds.el:

(nth 1 (assq 'workarea (frame-monitor-attributes frame))) ; For left
(nth 2 (assq 'workarea (frame-monitor-attributes frame))) ; For top

But he does not have Emacs 24.4, so no `frame-monitor-attributes'
(and that ultimately depends on C code, so I can't just send him
the latest frame.el code to test).

He did try substituting (- 1520) instead of 0 for the `left' value,
and that positioned the frame pretty much where it should be.

Dunno yet whether -1520 would do the same thing.  There is nothing
in the doc that indicates the formats (or types) of the components
of what is returned for `workarea' & `geometry' (there should be).
But Andy Moreton's feedback shows that the value can be something
like -1520.

If there is someone with Emacs 24.4 who could test my `maximize-frame'
code with the change I suggested (using the code above, instead
of 0, for left and top), that would be good.

Message #14 received at 18657 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 18657 <at> debbugs.gnu.org, 18637 <at> debbugs.gnu.org
Subject: Re: bug#18657: 24.4.50; positioning frames on multi-monitor displays
Date: Wed, 14 Jul 2021 00:00:15 +0200

Drew Adams <drew.adams <at> oracle.com> writes:

> Based on that, I've sent him an updated version of `maximize-frame'
> (from `frame-cmds.el'), which differs only in not using (0,0) as the
> position coordinates systematically.  Instead, it uses this:
>
> (nth 1 (assq 'workarea (frame-monitor-attributes frame))) ; For left
> (nth 2 (assq 'workarea (frame-monitor-attributes frame))) ; For right
>
> Andy, perhaps you could try that?

There doesn't really seem to be anything actionable in this bug report,
and not a lot in the parent report #18637, either.

I think for any progress to be made here, a report describing what
problem's you're seeing (if any, these days), and what you think should
be done about it should be filed.  But I'm closing this report and #18637.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #19 received at 18657 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "18657 <at> debbugs.gnu.org" <18657 <at> debbugs.gnu.org>,
 "18637 <at> debbugs.gnu.org" <18637 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#18657: 24.4.50; positioning frames on
 multi-monitor displays
Date: Tue, 13 Jul 2021 22:20:41 +0000

> There doesn't really seem to be anything actionable in this bug report,
> and not a lot in the parent report #18637, either.
> 
> I think for any progress to be made here, a report describing what
> problem's you're seeing (if any, these days), and what you think should
> be done about it should be filed.  But I'm closing this report and #18637.

Yet another "won't fix".

At least one other user (Andy M) agreed in these
threads that "the meaning of geometry/workarea
and the coordinate system [need to be] given a
little more detail in the docs."

Alas, the docs weren't touched (AFAIK).  Too bad.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.