unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: larsi@gnus.org, 9366@debbugs.gnu.org
Subject: bug#9366: Display geometry change hook
Date: Mon, 21 Sep 2020 09:26:01 +0200	[thread overview]
Message-ID: <5d5c2107-f7bf-62b1-85af-4acac89c7ce6@gmx.at> (raw)
In-Reply-To: <83tuvszjs0.fsf@gnu.org>

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





  reply	other threads:[~2020-09-21  7:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-25  5:16 bug#9366: Display geometry change hook David De La Harpe Golden
2011-08-25  5:55 ` Eli Zaretskii
2011-08-25 12:42   ` David De La Harpe Golden
2011-08-31 17:43 ` bug#9366: Attempting to add myself to this bug's CC list Edward O'Connor
2020-09-19 15:28 ` bug#9366: Display geometry change hook Lars Ingebrigtsen
2020-09-19 15:42   ` Eli Zaretskii
2020-09-20  8:14     ` martin rudalics
2020-09-20  8:25       ` Lars Ingebrigtsen
2020-09-20  8:56       ` Eli Zaretskii
2020-09-20 12:24         ` martin rudalics
2020-09-20 12:59           ` Eli Zaretskii
2020-09-21  7:26             ` martin rudalics [this message]
2020-09-21 14:21               ` Eli Zaretskii
2020-09-22  7:16                 ` martin rudalics
2020-09-22 14:16                   ` Eli Zaretskii
2020-09-23  7:15                     ` martin rudalics
2020-09-23  7:47                       ` Corwin Brust
2020-09-23  8:14                         ` martin rudalics
2020-09-23 14:35                           ` Eli Zaretskii
2020-09-23 14:29                       ` Eli Zaretskii
2020-09-23 17:41                         ` martin rudalics
2020-09-23 18:03                           ` Eli Zaretskii
2020-09-22 15:04                   ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5d5c2107-f7bf-62b1-85af-4acac89c7ce6@gmx.at \
    --to=rudalics@gmx.at \
    --cc=9366@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).