From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pedro Andres Aranda Gutierrez Newsgroups: gmane.emacs.devel Subject: Re: make-frame-command with multiple munitors Date: Wed, 21 Sep 2022 11:21:20 +0200 Message-ID: References: <875yhil2xw.fsf@yahoo.com> <87pmfpiic4.fsf@yahoo.com> <878rmdi8mc.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000004c1ce705e92c7914" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25214"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 21 11:27:05 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oaw0X-0006J1-CK for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Sep 2022 11:27:05 +0200 Original-Received: from localhost ([::1]:45664 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oaw0W-0002EB-3I for ged-emacs-devel@m.gmane-mx.org; Wed, 21 Sep 2022 05:27:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58058) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oavvR-00056g-TV for emacs-devel@gnu.org; Wed, 21 Sep 2022 05:21:49 -0400 Original-Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]:43927) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oavvQ-0007uU-3c for emacs-devel@gnu.org; Wed, 21 Sep 2022 05:21:49 -0400 Original-Received: by mail-ej1-x62d.google.com with SMTP id lh5so12136445ejb.10 for ; Wed, 21 Sep 2022 02:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=Z2lrJ2ZQGUT42uaMPGTGOw+C1AWn1Al8sKSJ5Q8PqCo=; b=HVa5wSqm3j/8U2lE+GNN2YF4MYBWstEBeWQnY/ELhFhnc3XyXLE0XdhkOzVOr0BA9e lNARZidLajmwTfVlbWXLJWT8+Aq3dCb3BOv/cwNs4SyrJqfwPQ3QK17X9Kq6/E8ID/PV +TZd29AUsH0wdMP6tKPwPgYj9VsMkcvVWY7qgcLcXa86nDNlbwXjCgcCtIW8SDkj+fNP TCbUgcAPDG1lVBMexdISY+NxeWpnkCQMSROdJ9HuzOOncYIFTfPoQlkbI0GwqTI4NHvN MMaBPaVwdNqMgDR7BtKWVVdMqqENEyi7FbrX8s6Jol9l1t+DW0lA9RP+yRA/vpNIQbYN e2pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=Z2lrJ2ZQGUT42uaMPGTGOw+C1AWn1Al8sKSJ5Q8PqCo=; b=uKgsaU5v/HTeq2VBH6kHRykmdchYRwf5aWWoBQSjDUfhFLdaQSu3hMYsR46wCDm/Gg NBTLt5IVnS0BsSU2bil+0uRh9h/MHRe6WnsKmBkKzXGao0c9B4RcZmABxkFSvAAmEwif WZyZCtcRcJY2kno4ZDFKPy1WnpSOpTpQL5daSSEWzjcNps1koJLWrly43Nbo6WlV8q96 4W4Y+S+ENHuf+8DKkroXm7AY4CqhBOfL3uwCAeHNjd56PqHtImWy5xonyTJwKkYCp0VI 3Zpe41hM73FwD0yx1ZUAW4ofGDzg3kHjNyZmQK+JjuO0syBocwmtP7r7crwJo2fQbmSs 0rZA== X-Gm-Message-State: ACrzQf053swQwuXb7TQRJSD1zAcrbK7iCqD6uS0VpTeAuVc28v67cPu4 J0Tdsx9Mgf/g3jcv27LIx/hPq+OX47vS+gsHN0U= X-Google-Smtp-Source: AMsMyM7VNRCcF6Atc7Ca9VcR2BQajcYPsf1431EiM0N3B6RjJapW785HqVIDxR6DOsI0K0YZGdy+jxh/sW+uVzou/sY= X-Received: by 2002:a17:906:5a6b:b0:73c:c9ee:8b5c with SMTP id my43-20020a1709065a6b00b0073cc9ee8b5cmr19741610ejc.310.1663752106415; Wed, 21 Sep 2022 02:21:46 -0700 (PDT) In-Reply-To: <878rmdi8mc.fsf@yahoo.com> Received-SPF: pass client-ip=2a00:1450:4864:20::62d; envelope-from=paaguti@gmail.com; helo=mail-ej1-x62d.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:295873 Archived-At: --0000000000004c1ce705e92c7914 Content-Type: text/plain; charset="UTF-8" I stand corrected ... this is what happens when the morning coffee has not yet kicked in and you write an email ;-) So, in my case, i observe that the root window both on my Linux Laptop and on the Macbook Pro coincides with the device's display. I have the device on my right and I place an additional physical display on the left. So the + 32 in my code is the equivalent I found to the (left . 32) (top .32) in the xx-frame-alist. And once again, it would be nice to have something to mimic the behaviour of my code in Emacs. I don't know, maybe an (on-active . t) in the xx-frame-alist??? Just a suggestion... /PA On Wed, 21 Sept 2022 at 07:45, Po Lu wrote: > Pedro Andres Aranda Gutierrez writes: > > > OK... a longer answer ;-) the moment you include (top . xxx) or (left > > . xxx) in the (default|init)-frame-alist the vales are taken as > > absolute values in the window manager's space, and Emacs will be > > placed (normally) somewhere in the display that is designated as 0 > > (the Linux laptop or MacBook Pro) independently of which display you > > were when you lunched Emacs. > > Well yes, that's intentional behavior. Setting `top' or `left' tells > the window manager to try very hard to place the frame at the specified > location on the screen. If you want the frame to be placed at the > correct location, you will have to either remove both position > parameters from initial-frame-alist, for it to be positioned by the WM, > or manually specify the position of the monitor you want. > > A note about terminology from the POV of Emacs: the normal coordinate > space of a connection to the X server (the connection is referred to as > a "display") is relative to the root window of the display's default > screen. A screen is then split into different "monitors", which are > potentially overlapping rectangular subsets of the screen's root window, > normally displayed in a single physical monitor, not counting overscan > or underscan. > > `top' and `left' coordinates are specified relative to the root window > of the screen, not "in the display that is designated to 0", nor is such > a coordinate system affected by the monitor in which the initial frame > was created. Where in the root window coordinate system individual > monitors are placed can only be determined by the output of > display-monitor-attributes-list. > -- Fragen sind nicht da um beantwortet zu werden, Fragen sind da um gestellt zu werden Georg Kreisler Headaches with a Juju log: unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run a leader-deposed hook here, but we can't yet --0000000000004c1ce705e92c7914 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I stand corrected ... this is what happens when the mornin= g coffee has not yet kicked in and you write an email ;-)

So, = in my case, i observe that the root window both on my Linux Laptop and on t= he Macbook Pro coincides with the device's display.
I have th= e device on my right and I place an additional physical display on the left= . So the=C2=A0+ 32 in my code is the equivalent I found
to = the (left . 32) (top .32) in the xx-frame-alist.=C2=A0

=
And once again, it would be nice to have something to mimic the behavi= our of my code in Emacs. I don't know, maybe an=C2=A0
(on-act= ive . t)=C2=A0 in the xx-frame-alist???

Just a sug= gestion...
=C2=A0/PA=C2=A0

On Wed, 21 Sept 2022 at 07:45, Po= Lu <luangruo@yahoo.com> wr= ote:
Pedro Andre= s Aranda Gutierrez <paaguti@gmail.com> writes:

> OK... a longer answer ;-) the moment you include (top . xxx) or (left<= br> > . xxx) in the (default|init)-frame-alist the vales are taken as
> absolute values in the window manager's space, and Emacs will be > placed (normally) somewhere in the display that is designated as 0
> (the Linux laptop or MacBook Pro) independently of which display you > were when you lunched Emacs.

Well yes, that's intentional behavior.=C2=A0 Setting `top' or `left= ' tells
the window manager to try very hard to place the frame at the specified
location on the screen.=C2=A0 If you want the frame to be placed at the
correct location, you will have to either remove both position
parameters from initial-frame-alist, for it to be positioned by the WM,
or manually specify the position of the monitor you want.

A note about terminology from the POV of Emacs: the normal coordinate
space of a connection to the X server (the connection is referred to as
a "display") is relative to the root window of the display's = default
screen.=C2=A0 A screen is then split into different "monitors", w= hich are
potentially overlapping rectangular subsets of the screen's root window= ,
normally displayed in a single physical monitor, not counting overscan
or underscan.

`top' and `left' coordinates are specified relative to the root win= dow
of the screen, not "in the display that is designated to 0", nor = is such
a coordinate system affected by the monitor in which the initial frame
was created.=C2=A0 Where in the root window coordinate system individual monitors are placed can only be determined by the output of
display-monitor-attributes-list.


--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um = gestellt zu werden
Georg Kreisler

Headach= es with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.u= niter.operation we should run a leader-deposed hook here, but we can't = yet

--0000000000004c1ce705e92c7914--