GNU bug report logs -
#53793
29.0.50; 'fullscreen' frame parameter on pgtk
Previous Next
Reported by: Augusto Stoffel <arstoffel <at> gmail.com>
Date: Sat, 5 Feb 2022 08:57:01 UTC
Severity: normal
Found in version 29.0.50
Done: Po Lu <luangruo <at> yahoo.com>
Bug is archived. No further changes may be made.
Full log
Message #49 received at 53793 <at> debbugs.gnu.org (full text, mbox):
On Wed, 9 Feb 2022 at 09:45, martin rudalics <rudalics <at> gmx.at> wrote:
>> (But I still think it would be nice – and reduce confusion – to extend
>> `move-frame-functions'.)
>
> 'move-frame-functions' has one modest purpose: Catch the case where a
> frame gets moved but _not_ resized. This should be useful to avoid a
> timer when trying to synchronize side by side frames like a speedbar
> attached to a normal frame (without resorting to a timer)
The speedbar is created with the same height as the attached frame. For
sure you would also want to synchronize their heights in the event of a
resize? (And not only if the main frame is resized from the top edge,
of course.)
> or a frame that should be positioned at a precise location on top of a
> normal frame (like a native tooltip frame that doesn't vanish on
> input).
What if the “precise location” is stipulated relative to the bottom
right corner of the frame? I wish I could stick a clock at the bottom
right of the main frame, as if it was part of the echo area but right
aligned.
> To catch resizing 'move-frame-functions' is much too noisy.
Any of the things above can be achieve by adding the same function to
both 'move-frame-functions' and 'window-size-change-functions', but that
indeed seems to much noise.
Resizing a frame is just as rare as moving it, and much less common than
changing window configurations, so I don't understand the concern.
>
> martin
This bug report was last modified 3 years and 104 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.