Re: Re: Re: make-frame-command with multiple munitors

Re: Re: Re: make-frame-command with multiple munitors

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

Christopher Dimech <dimech@gmx.com> writes:

> Emacs has the capability of placing a frame at some position.  It is then
> logical for emacs to look into the monitor configuration to determine the
> current monitor (then placing at corners or center oy monitor).  It would
> a feature very much appreciated if made to happen.

+1. I'm doing it on my own with:

(defun reposition-after-init ()
  "Re-position the frame in a display (Only for emacs 29 and above)"
  (when (> emacs-major-version 28)
    (let* ((monitor-attributes (frame-monitor-attributes))
           (work-area (assq 'workarea monitor-attributes))
           (x-min (nth 1 work-area))
           (y-min (nth 2 work-area))
           (new-x  (+ x-min 32))
           (new-y  (+ y-min 32)))
      (message "work-area: %s -> %d %d" work-area new-x new-y)
      (set-frame-position (selected-frame) new-x new-y))))

Hooked to the startup in

(add-hook #'after-init-hook #'reposition-after-init)

This works when you do NOT specify (left or top) in the default-frame-alist
or initial-frame-alist

It would be nice to have a (current-monitor . t) in the default-frame-alist
or initial-frame-alist to do this ;-)

//PA

PS: tested on X and mac
-- 
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

[-- Attachment #2: Type: text/html, Size: 2179 bytes --]

Re: make-frame-command with multiple munitors

[Emanuel Berg]

Pedro Andres Aranda Gutierrez wrote:

>> Emacs has the capability of placing a frame at some
>> position. It is then logical for emacs to look into the
>> monitor configuration to determine the current monitor
>> (then placing at corners or center oy monitor). It would
>> a feature very much appreciated if made to happen.
>
> +1

`1+'

-- 
underground experts united
https://dataswamp.org/~incal

Re: make-frame-command with multiple munitors

[Po Lu]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> Christopher Dimech <dimech@gmx.com> writes:
>
>> Emacs has the capability of placing a frame at some position.  It is then
>> logical for emacs to look into the monitor configuration to determine the
>> current monitor (then placing at corners or center oy monitor).  It would
>> a feature very much appreciated if made to happen.
>
> +1. I'm doing it on my own with:
> (defun reposition-after-init ()
>   "Re-position the frame in a display (Only for emacs 29 and above)"
>   (when (> emacs-major-version 28)
>     (let* ((monitor-attributes (frame-monitor-attributes))
>            (work-area (assq 'workarea monitor-attributes))
>            (x-min (nth 1 work-area))
>            (y-min (nth 2 work-area))
>            (new-x  (+ x-min 32))
>            (new-y  (+ y-min 32)))
>       (message "work-area: %s -> %d %d" work-area new-x new-y)
>       (set-frame-position (selected-frame) new-x new-y))))
> Hooked to the startup in
>
> (add-hook #'after-init-hook #'reposition-after-init)
>
> This works when you do NOT specify (left or top) in the default-frame-alist or initial-frame-alist 
>
> It would be nice to have a (current-monitor . t) in the default-frame-alist or initial-frame-alist to do this ;-)

What window manager are you using?

Re: make-frame-command with multiple munitors

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]

That code works on GNOME and macOS

On Tue, 20 Sept 2022 at 13:07, Po Lu <luangruo@yahoo.com> wrote:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
> > Christopher Dimech <dimech@gmx.com> writes:
> >
> >> Emacs has the capability of placing a frame at some position.  It is
> then
> >> logical for emacs to look into the monitor configuration to determine
> the
> >> current monitor (then placing at corners or center oy monitor).  It
> would
> >> a feature very much appreciated if made to happen.
> >
> > +1. I'm doing it on my own with:
> > (defun reposition-after-init ()
> >   "Re-position the frame in a display (Only for emacs 29 and above)"
> >   (when (> emacs-major-version 28)
> >     (let* ((monitor-attributes (frame-monitor-attributes))
> >            (work-area (assq 'workarea monitor-attributes))
> >            (x-min (nth 1 work-area))
> >            (y-min (nth 2 work-area))
> >            (new-x  (+ x-min 32))
> >            (new-y  (+ y-min 32)))
> >       (message "work-area: %s -> %d %d" work-area new-x new-y)
> >       (set-frame-position (selected-frame) new-x new-y))))
> > Hooked to the startup in
> >
> > (add-hook #'after-init-hook #'reposition-after-init)
> >
> > This works when you do NOT specify (left or top) in the
> default-frame-alist or initial-frame-alist
> >
> > It would be nice to have a (current-monitor . t) in the
> default-frame-alist or initial-frame-alist to do this ;-)
>
> What window manager are you using?
>


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

[-- Attachment #2: Type: text/html, Size: 2596 bytes --]

Re: make-frame-command with multiple munitors

[Po Lu]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> That code works on GNOME and macOS

Don't the GNOME and Mac OS window managers do that automatically?

Re: make-frame-command with multiple munitors

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

Nope...
/PA

On Wed, 21 Sept 2022 at 04:15, Po Lu <luangruo@yahoo.com> wrote:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
> > That code works on GNOME and macOS
>
> Don't the GNOME and Mac OS window managers do that automatically?
>


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

[-- Attachment #2: Type: text/html, Size: 1079 bytes --]

Re: make-frame-command with multiple munitors

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

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.

Rechecked on GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.20, cairo version 1.16.0) of 2022-09-17

/PA

On Wed, 21 Sept 2022 at 07:08, Pedro Andres Aranda Gutierrez <
paaguti@gmail.com> wrote:

> Nope...
> /PA
>
> On Wed, 21 Sept 2022 at 04:15, Po Lu <luangruo@yahoo.com> wrote:
>
>> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>>
>> > That code works on GNOME and macOS
>>
>> Don't the GNOME and Mac OS window managers do that automatically?
>>
>
>
> --
> 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
>
>

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

[-- Attachment #2: Type: text/html, Size: 2467 bytes --]

Re: make-frame-command with multiple munitors

[Po Lu]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> 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.

Re: make-frame-command with multiple munitors

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]

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 <luangruo@yahoo.com> wrote:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> 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

[-- Attachment #2: Type: text/html, Size: 3502 bytes --]

Re: make-frame-command with multiple munitors

[Po Lu]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

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

"Device's display?"

Which of "display", "screen" or "monitor" do you mean by that?

Re: make-frame-command with multiple munitors

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

Well... if I'm on the Linux laptop it's the laptop's TFT and if I'm on the
macbook Pro, I mean the Macbook Pro's TFT ...

/PA

On Wed, 21 Sept 2022 at 12:53, Po Lu <luangruo@yahoo.com> wrote:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
> > 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.
>
> "Device's display?"
>
> Which of "display", "screen" or "monitor" do you mean by that?
>


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

[-- Attachment #2: Type: text/html, Size: 1739 bytes --]

Re: make-frame-command with multiple munitors

[Po Lu]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> Well... if I'm on the Linux laptop it's the laptop's TFT and if I'm on
> the macbook Pro, I mean the Macbook Pro's TFT ...

Then as I said, the TRT is to get the offsets from
display-monitor-attributes-alist and to use those.