GNU bug report logs -
#9366
Display geometry change hook
Previous Next
Full log
Message #41 received at 9366 <at> debbugs.gnu.org (full text, mbox):
> 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.
This bug report was last modified 4 years and 263 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.