GNU bug report logs - #9366
Display geometry change hook

Previous Next

To reply to this bug, email your comments to 9366 AT debbugs.gnu.org.

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

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

From: David De La Harpe Golden <david <at> harpegolden.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Display geometry change hook
Date: Thu, 25 Aug 2011 06:16:58 +0100

[Message part 1 (text/plain, inline)]

Severity: wishlist

Raised by Edward O'Connor in emacs-devel thread [1], filing in 
bugtracker so it doesn't get lost over the feature freeze period.

Emacs doesn't appear to currently provide a hook that is reliably called 
when the _display_ geometry changes on graphical window systems. e.g. 
screen resolution changed by user, monitor hotplugging.

Emacs frame/window geometry might sometimes be considered to remain the 
same by the window system terms despite changing overall display 
geometry, so e.g. window-configuration-change-hook is not always run 
when the display geometry changes.

Attached is an initial x11-only stab at an implementation that calls 
window-configuration-change-hook when display geometry changes, though a 
separate hook would be another design option.

For ns, Edward also mentioned:

"On GNUStep and Mac OS X, applications can listen for 
NSApplicationDidChangeScreenParametersNotification for this sort of thing"

Dunno about w32 as yet, but presumably it has something similar.


[1] http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00544.html
From: "Edward O'Connor" <...>
Date: Fri, 12 Aug 2011 10:51:25 -0700
Message-ID: 
<CAME3nGLnjLXixmSY45BWFX6qtCp2_XBR4x6a281hO6Mu=rnSuQ <at> mail.gmail.com>
Subject: is there a hook run when display geometry changes?

[xrandr_monitoring_r1.diff (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: David De La Harpe Golden <david <at> harpegolden.net>
Cc: 9366 <at> debbugs.gnu.org
Subject: Re: bug#9366: Display geometry change hook
Date: Thu, 25 Aug 2011 08:55:09 +0300

> Date: Thu, 25 Aug 2011 06:16:58 +0100
> From: David De La Harpe Golden <david <at> harpegolden.net>
> 
> Dunno about w32 as yet, but presumably it has something similar.

On MS-Windows there's the WM_DISPLAYCHANGE message sent to the message
pump.  Emacs already accepts that message (see w32term.c), but
currently does nothing with it except announcing the change to the
attached debugger.

However, on Windows the message also specifies the new resolution, so
this:

> +        inev.ie.kind = SCREEN_CHANGE_NOTIFY_EVENT;
> +        inev.ie.frame_or_window = XCAR(dpyinfo->name_list_element);

is not general enough: there should be a way to provide the new
dimensions to the event queue.  It also means that a "normal" hook is
insufficient to handle this event, it should be a -functions style
hook.

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

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9366 <at> debbugs.gnu.org
Subject: Re: bug#9366: Display geometry change hook
Date: Thu, 25 Aug 2011 13:42:29 +0100

On 25/08/11 06:55, Eli Zaretskii wrote:
>> Date: Thu, 25 Aug 2011 06:16:58 +0100
>> From: David De La Harpe Golden<david <at> harpegolden.net>
>>
>> Dunno about w32 as yet, but presumably it has something similar.
>
> On MS-Windows there's the WM_DISPLAYCHANGE message sent to the message
> pump.  Emacs already accepts that message (see w32term.c), but
> currently does nothing with it except announcing the change to the
> attached debugger.
>
> However, on Windows the message also specifies the new resolution, so
> this:
>

Technically the incoming x11 event does too, but as you can re-query 
with the existing #'display-pixel-width etc. functions (and get the new 
values) anyway by the time the hook actually runs (on x11), wasn't sure 
we needed to allow for propagation of the info really.

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

From: "Edward O'Connor" <hober0 <at> gmail.com>
To: 9366 <at> debbugs.gnu.org
Subject: Attempting to add myself to this bug's CC list
Date: Wed, 31 Aug 2011 10:43:16 -0700

I apologize for the noise; the normal way of CCing oneself apparently
doesn't work[1].


Ted

1. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5439

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: David De La Harpe Golden <david <at> harpegolden.net>
Cc: 9366 <at> debbugs.gnu.org
Subject: Re: bug#9366: Display geometry change hook
Date: Sat, 19 Sep 2020 17:28:48 +0200

David De La Harpe Golden <david <at> harpegolden.net> writes:

> Attached is an initial x11-only stab at an implementation that calls
> window-configuration-change-hook when display geometry changes, though
> a separate hook would be another design option.
>
> For ns, Edward also mentioned:
>
> "On GNUStep and Mac OS X, applications can listen for
> NSApplicationDidChangeScreenParametersNotification for this sort of
> thing"
>
> Dunno about w32 as yet, but presumably it has something similar.

This was nine years ago, but this didn't get much attention at the time.

[...]

> +if test "${HAVE_X11}" = "yes"; then
> +  if test "${with_xrandr}" != "no"; then
> +    PKG_CHECK_MODULES(XRANDR, xrandr > 1.0, HAVE_XRANDR=yes, HAVE_XRANDR=no)
> +    if test "${HAVE_XRANDR}" = "yes"; then
> +      AC_DEFINE(HAVE_XRANDR, 1, [Define to 1 if you have the Xrandr library (-lXrandr).])
> +    fi

Emacs is now built with xrandr support by default (on the relevant
systems)...

[...]

> +#ifdef HAVE_XRANDR
> +    /* xrandr extension may or may not be present on a display =>
> +       can't check for it as a constant C "case" arg, hence "if" here  */
> +    if (dpyinfo->xrandr_present &&
> +        (event.type == (dpyinfo->xrandr_event_base + RRScreenChangeNotify)))
> +      {
> +        /* FIXME: is XRRUpdateConfiguration actually called by the toolkit/gtk+?

But looking through the code, it doesn't seem like Emacs has grown this
capability over the years?  But I may be looking in the wrong places.

In any case, it sounds useful?  I haven't tried applying the patch,
though, so I don't know how much work that would be to bring it up to
date.

Anybody got any opinions here?

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, martin rudalics <rudalics <at> gmx.at>
Cc: 9366 <at> debbugs.gnu.org, david <at> harpegolden.net
Subject: Re: bug#9366: Display geometry change hook
Date: Sat, 19 Sep 2020 18:42:23 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sat, 19 Sep 2020 17:28:48 +0200
> Cc: 9366 <at> debbugs.gnu.org
> 
> > +#ifdef HAVE_XRANDR
> > +    /* xrandr extension may or may not be present on a display =>
> > +       can't check for it as a constant C "case" arg, hence "if" here  */
> > +    if (dpyinfo->xrandr_present &&
> > +        (event.type == (dpyinfo->xrandr_event_base + RRScreenChangeNotify)))
> > +      {
> > +        /* FIXME: is XRRUpdateConfiguration actually called by the toolkit/gtk+?
> 
> But looking through the code, it doesn't seem like Emacs has grown this
> capability over the years?  But I may be looking in the wrong places.
> 
> In any case, it sounds useful?  I haven't tried applying the patch,
> though, so I don't know how much work that would be to bring it up to
> date.
> 
> Anybody got any opinions here?

Do we really have to do this on such a low level?  Why cannot we call
such a hook from change_frame_size, which would allow us to do that in
platform-independent manner?

Martin, am I missing something here?

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 9366 <at> debbugs.gnu.org, david <at> harpegolden.net
Subject: Re: bug#9366: Display geometry change hook
Date: Sun, 20 Sep 2020 10:14:34 +0200

> Do we really have to do this on such a low level?  Why cannot we call
> such a hook from change_frame_size, which would allow us to do that in
> platform-independent manner?
>
> Martin, am I missing something here?

Would change_frame_size be aware of such a geometry change?  IIUC
the original request

https://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00544.html

Edward would really just want a completely separate hook that reports to
Emacs the identity of the changed display and maybe its new geometry and
is only called in those, IMO very rare, occasions.  Or what am I missing
here?

martin

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 9366 <at> debbugs.gnu.org, david <at> harpegolden.net
Subject: Re: bug#9366: Display geometry change hook
Date: Sun, 20 Sep 2020 10:25:31 +0200

martin rudalics <rudalics <at> gmx.at> writes:

> Edward would really just want a completely separate hook that reports to
> Emacs the identity of the changed display and maybe its new geometry and
> is only called in those, IMO very rare, occasions.  Or what am I missing
> here?

No, I think that's it -- it's a hook that's run when the display changes
size, not when any Emacs frame changes size.

But I wonder whether triggering this from an xrandr context makes much
sense these days.  Surely on most (any?) modern GNU/Linux systems,
plugging in a new screen will trigger a Dbus message?

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: larsi <at> gnus.org, 9366 <at> debbugs.gnu.org, david <at> harpegolden.net
Subject: Re: bug#9366: Display geometry change hook
Date: Sun, 20 Sep 2020 11:56:02 +0300

> Cc: david <at> harpegolden.net, 9366 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Sun, 20 Sep 2020 10:14:34 +0200
> 
>  > Do we really have to do this on such a low level?  Why cannot we call
>  > such a hook from change_frame_size, which would allow us to do that in
>  > platform-independent manner?
>  >
>  > Martin, am I missing something here?
> 
> Would change_frame_size be aware of such a geometry change?  IIUC
> the original request
> 
> https://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00544.html
> 
> Edward would really just want a completely separate hook that reports to
> Emacs the identity of the changed display and maybe its new geometry and
> is only called in those, IMO very rare, occasions.  Or what am I missing
> here?

So this is only about switching to a different display?  And you are
saying that Emacs in general doesn't know about such display changes?

Would it work to test the display geometry from focus-in-hook?  Or
from a timer?

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 9366 <at> debbugs.gnu.org, david <at> harpegolden.net
Subject: Re: bug#9366: Display geometry change hook
Date: Sun, 20 Sep 2020 14:24:10 +0200

> So this is only about switching to a different display?

A different geometry but still on the same display IIUC.

> And you are
> saying that Emacs in general doesn't know about such display changes?

I don't know.  Are we already informed when the user plugs in a new
display?

> Would it work to test the display geometry from focus-in-hook?

Sounds expensive (BTW 'focus-in-hook' is obsolete since 27.1).  And what
about a user who currently has no frame on that display but might
consider switching to it when its geometry meets certain requirements?

> Or
> from a timer?

To poll the geometry?  Sounds much too expensive too.  If and when the
underlying windowing system informs us of display changes, I would just
react to them.  What's speaking against it?

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: larsi <at> gnus.org, 9366 <at> debbugs.gnu.org, david <at> harpegolden.net
Subject: Re: bug#9366: Display geometry change hook
Date: Sun, 20 Sep 2020 15:59:11 +0300

> Cc: larsi <at> gnus.org, david <at> harpegolden.net, 9366 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Sun, 20 Sep 2020 14:24:10 +0200
> 
>  > Would it work to test the display geometry from focus-in-hook?
> 
> Sounds expensive

How so?  Is the API which we use to determine the display geometry
expensive?  Any quantitative data about that?

> And what about a user who currently has no frame on that display but
> might consider switching to it when its geometry meets certain
> requirements?

Is this an important use case?

>  > Or
>  > from a timer?
> 
> To poll the geometry?  Sounds much too expensive too.

Same question as above.  We currently have several timers running in
every session, so a timer that ticks, say, once a second doesn't sound
too expensive to me.  Especially since this will most probably be an
optional feature.

> If and when the underlying windowing system informs us of display
> changes, I would just react to them.  What's speaking against it?

The proposed solution was only for X, and using an optional component
at that.  I'd rather find a solution that would work on all supported
platforms and required no special APIs.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 9366 <at> debbugs.gnu.org, david <at> harpegolden.net
Subject: Re: bug#9366: Display geometry change hook
Date: Mon, 21 Sep 2020 09:26:01 +0200

>>   > Would it work to test the display geometry from focus-in-hook?
>>
>> Sounds expensive
>
> How so?  Is the API which we use to determine the display geometry
> expensive?

I meant expensive in the sense that Emacs would poll the display
geometry in every focus event with maybe a handful of people ever making
use of it.

> Any quantitative data about that?
>
>> And what about a user who currently has no frame on that display but
>> might consider switching to it when its geometry meets certain
>> requirements?
>
> Is this an important use case?

I don't know.  I never plug a monitor into a running session.

>>   > Or
>>   > from a timer?
>>
>> To poll the geometry?  Sounds much too expensive too.
>
> Same question as above.  We currently have several timers running in
> every session, so a timer that ticks, say, once a second doesn't sound
> too expensive to me.  Especially since this will most probably be an
> optional feature.

You mean when the value of 'display-geometry-change-hook' is non-nil,
for example.

>> If and when the underlying windowing system informs us of display
>> changes, I would just react to them.  What's speaking against it?
>
> The proposed solution was only for X, and using an optional component
> at that.  I'd rather find a solution that would work on all supported
> platforms and required no special APIs.

But it would probably rely on 'display-monitor-attributes-list' and thus
use its APIs.  And on Windows, for example, the "special" API is already
there in WM_DISPLAYCHANGE and I suppose the other platforms should be
able to handle fullscreen frames after a display change in a similar way
too.

In either case it's no great deal.  I won't implement it because I've
sworn to never change the resolution of a running system again (once an
xfce Debian here insisted for weeks to come up with a 640x480 screen
resolution because it did not trust my monitor's repeat frequency) and
master still struggles with the (funcall eldoc-documentation-function)
issue.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: larsi <at> gnus.org, 9366 <at> debbugs.gnu.org, david <at> harpegolden.net
Subject: Re: bug#9366: Display geometry change hook
Date: Mon, 21 Sep 2020 17:21:10 +0300

> Cc: larsi <at> gnus.org, david <at> harpegolden.net, 9366 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Mon, 21 Sep 2020 09:26:01 +0200
> 
>  >> To poll the geometry?  Sounds much too expensive too.
>  >
>  > Same question as above.  We currently have several timers running in
>  > every session, so a timer that ticks, say, once a second doesn't sound
>  > too expensive to me.  Especially since this will most probably be an
>  > optional feature.
> 
> You mean when the value of 'display-geometry-change-hook' is non-nil,
> for example.

Yes.

>  >> If and when the underlying windowing system informs us of display
>  >> changes, I would just react to them.  What's speaking against it?
>  >
>  > The proposed solution was only for X, and using an optional component
>  > at that.  I'd rather find a solution that would work on all supported
>  > platforms and required no special APIs.
> 
> But it would probably rely on 'display-monitor-attributes-list' and thus
> use its APIs.  And on Windows, for example, the "special" API is already
> there in WM_DISPLAYCHANGE and I suppose the other platforms should be
> able to handle fullscreen frames after a display change in a similar way
> too.

Yes, I know about WM_DISPLAYCHANGE (although we currently only handle
the full-screen frames there).  But the corresponding X feature
requires the use of a special X module, and I don't know what happens
on macOS.  So I thought a platform-independent method that always
works, and can be implemented in just one place, is a better
alternative.

Besides, adding one more special event comes with minor disadvantages
of its own -- one more event to disregard in situations like
while-no-input etc.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 9366 <at> debbugs.gnu.org, david <at> harpegolden.net
Subject: Re: bug#9366: Display geometry change hook
Date: Tue, 22 Sep 2020 09:16:58 +0200

> Yes, I know about WM_DISPLAYCHANGE (although we currently only handle
> the full-screen frames there).

Has anyone ever confirmed that it correctly handles the full-screen
frames?

> But the corresponding X feature
> requires the use of a special X module, and I don't know what happens
> on macOS.  So I thought a platform-independent method that always
> works, and can be implemented in just one place, is a better
> alternative.

But such a platform-independent method on X would boil down to using the
same special X module as the platform-dependent method.  That is, we
would try running XRANDR in either case ...  I don't know about macOS.

> Besides, adding one more special event comes with minor disadvantages
> of its own -- one more event to disregard in situations like
> while-no-input etc.

But at least on Windows we have to pay attention to such events anyway.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: larsi <at> gnus.org, 9366 <at> debbugs.gnu.org, david <at> harpegolden.net
Subject: Re: bug#9366: Display geometry change hook
Date: Tue, 22 Sep 2020 17:16:58 +0300

> Cc: larsi <at> gnus.org, david <at> harpegolden.net, 9366 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Tue, 22 Sep 2020 09:16:58 +0200
> 
>  > Yes, I know about WM_DISPLAYCHANGE (although we currently only handle
>  > the full-screen frames there).
> 
> Has anyone ever confirmed that it correctly handles the full-screen
> frames?

I don't know.  I don't have a system to try that.

>  > But the corresponding X feature
>  > requires the use of a special X module, and I don't know what happens
>  > on macOS.  So I thought a platform-independent method that always
>  > works, and can be implemented in just one place, is a better
>  > alternative.
> 
> But such a platform-independent method on X would boil down to using the
> same special X module as the platform-dependent method.  That is, we
> would try running XRANDR in either case ...

Do we use XRANDR to query the display geometry?

>  > Besides, adding one more special event comes with minor disadvantages
>  > of its own -- one more event to disregard in situations like
>  > while-no-input etc.
> 
> But at least on Windows we have to pay attention to such events anyway.

I didn't mean MS-Windows events (a.k.a. "messages"), I meant events in
the Emacs event queue.  A message coming from the window manager
doesn't have to be converted to an Emacs event, it can be handled
directly.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 9366 <at> debbugs.gnu.org, david <at> harpegolden.net
Subject: Re: bug#9366: Display geometry change hook
Date: Tue, 22 Sep 2020 17:04:20 +0200

martin rudalics <rudalics <at> gmx.at> writes:

> But such a platform-independent method on X would boil down to using the
> same special X module as the platform-dependent method.  That is, we
> would try running XRANDR in either case ...  I don't know about macOS.

Does XRANDR work under Wayland?

Like I said earlier, it seems more useful to do this off of Dbus than in
a XRANDR context -- that's likely to be relevant for more systems, I think.

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

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 9366 <at> debbugs.gnu.org, david <at> harpegolden.net
Subject: Re: bug#9366: Display geometry change hook
Date: Wed, 23 Sep 2020 09:15:16 +0200

>> Has anyone ever confirmed that it correctly handles the full-screen
>> frames?
>
> I don't know.  I don't have a system to try that.

Maybe someone on Windows could give it a try:

(1) With an Emacs frame run 'toggle-frame-fullscreen' (F11).

(2) Change the resolution of the monitor the frame appears on.

(3) Look whether the frame is still fullscreen.

> Do we use XRANDR to query the display geometry?

If they are available, Emacs tries XRANDR first and, if that fails,
XINERAMA next.

> I didn't mean MS-Windows events (a.k.a. "messages"), I meant events in
> the Emacs event queue.  A message coming from the window manager
> doesn't have to be converted to an Emacs event, it can be handled
> directly.

You mean that we'd have to put a function running the hook into the
event queue when no input is allowed?  And running 'gui_set_fullscreen'
OTOH can be handled directly?

martin

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

From: Corwin Brust <corwin <at> bru.st>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 9366 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#9366: Display geometry change hook
Date: Wed, 23 Sep 2020 02:47:44 -0500

Hi Martin.

On Wed, Sep 23, 2020 at 2:16 AM martin rudalics <rudalics <at> gmx.at> wrote:
>
>  >> Has anyone ever confirmed that it correctly handles the full-screen
>  >> frames?
>  >
>  > I don't know.  I don't have a system to try that.
>
> Maybe someone on Windows could give it a try:
>
> (1) With an Emacs frame run 'toggle-frame-fullscreen' (F11).
>
> (2) Change the resolution of the monitor the frame appears on.
>
> (3) Look whether the frame is still fullscreen.

The frame remains full screen, both when immediately when I make the
change and also when I choose "revert".   When I selected "revert" it
did drop briefly out of full-screen mode but then restored itself
properly immediately thereafter.  I have several displays and most of
them have a full-screen emacs in them most of the time.  LMK if there
else I could assist with.  Emacs 27.1 GNU bin dist.

>
> martin

Regards,
Corwin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Corwin Brust <corwin <at> bru.st>
Cc: 9366 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#9366: Display geometry change hook
Date: Wed, 23 Sep 2020 10:14:37 +0200

>> Maybe someone on Windows could give it a try:
>>
>> (1) With an Emacs frame run 'toggle-frame-fullscreen' (F11).
>>
>> (2) Change the resolution of the monitor the frame appears on.
>>
>> (3) Look whether the frame is still fullscreen.
>
> The frame remains full screen, both when immediately when I make the
> change and also when I choose "revert".   When I selected "revert" it
> did drop briefly out of full-screen mode but then restored itself
> properly immediately thereafter.  I have several displays and most of
> them have a full-screen emacs in them most of the time.  LMK if there
> else I could assist with.  Emacs 27.1 GNU bin dist.

Thanks.  That last sentence makes me doubt whether you really tested
this on Windows.  What is a "GNU bin dist"?  Please clarify.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: larsi <at> gnus.org, 9366 <at> debbugs.gnu.org, david <at> harpegolden.net
Subject: Re: bug#9366: Display geometry change hook
Date: Wed, 23 Sep 2020 17:29:42 +0300

> Cc: larsi <at> gnus.org, david <at> harpegolden.net, 9366 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Wed, 23 Sep 2020 09:15:16 +0200
> 
>  > Do we use XRANDR to query the display geometry?
> 
> If they are available, Emacs tries XRANDR first and, if that fails,
> XINERAMA next.

Then maybe the proposed method is not a big deal.  But I'd like to
understand the situation on macOS first -- is there an equivalent
feature there?

>  > I didn't mean MS-Windows events (a.k.a. "messages"), I meant events in
>  > the Emacs event queue.  A message coming from the window manager
>  > doesn't have to be converted to an Emacs event, it can be handled
>  > directly.
> 
> You mean that we'd have to put a function running the hook into the
> event queue when no input is allowed?

Sorry, I don't think I understand this.  Can you explain what you
mean?

> And running 'gui_set_fullscreen' OTOH can be handled directly?

We already do that, no?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: larsi <at> gnus.org, corwin <at> bru.st, 9366 <at> debbugs.gnu.org
Subject: Re: bug#9366: Display geometry change hook
Date: Wed, 23 Sep 2020 17:35:46 +0300

> Cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
>  9366 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Wed, 23 Sep 2020 10:14:37 +0200
> 
>  > The frame remains full screen, both when immediately when I make the
>  > change and also when I choose "revert".   When I selected "revert" it
>  > did drop briefly out of full-screen mode but then restored itself
>  > properly immediately thereafter.  I have several displays and most of
>  > them have a full-screen emacs in them most of the time.  LMK if there
>  > else I could assist with.  Emacs 27.1 GNU bin dist.
> 
> Thanks.  That last sentence makes me doubt whether you really tested
> this on Windows.  What is a "GNU bin dist"?  Please clarify.

I'm guessing that's the Windows binaries available from the GNU FTP
site.  So we are safe, I think.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 9366 <at> debbugs.gnu.org, david <at> harpegolden.net
Subject: Re: bug#9366: Display geometry change hook
Date: Wed, 23 Sep 2020 19:41:40 +0200

>>   > I didn't mean MS-Windows events (a.k.a. "messages"), I meant events in
>>   > the Emacs event queue.  A message coming from the window manager
>>   > doesn't have to be converted to an Emacs event, it can be handled
>>   > directly.
>>
>> You mean that we'd have to put a function running the hook into the
>> event queue when no input is allowed?
>
> Sorry, I don't think I understand this.  Can you explain what you
> mean?
>
>> And running 'gui_set_fullscreen' OTOH can be handled directly?
>
> We already do that, no?

I probably didn't understand what you wrote first.  Let me ask it this
way: Since we can run 'gui_set_fullscreen' directly, then couldn't we
run 'display-geometry-change-hook' directly too?

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: larsi <at> gnus.org, 9366 <at> debbugs.gnu.org, david <at> harpegolden.net
Subject: Re: bug#9366: Display geometry change hook
Date: Wed, 23 Sep 2020 21:03:25 +0300

> Cc: larsi <at> gnus.org, david <at> harpegolden.net, 9366 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Wed, 23 Sep 2020 19:41:40 +0200
> 
> Let me ask it this way: Since we can run 'gui_set_fullscreen'
> directly, then couldn't we run 'display-geometry-change-hook'
> directly too?

I think so, yes.

Previous Next

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