GNU bug report logs - #9366
Display geometry change hook

Previous Next

Package: emacs;

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

Date: Thu, 25 Aug 2011 05:20:02 UTC

Severity: wishlist

Full log


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.




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.