GNU bug report logs - #53793
29.0.50; 'fullscreen' frame parameter on pgtk

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: Po Lu <luangruo <at> yahoo.com>, Stephen Berman <stephen.berman <at> gmx.net>,
 53793 <at> debbugs.gnu.org
Subject: Re: bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk
Date: Wed, 9 Feb 2022 19:25:12 +0100

>> '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.)

Obviously.  Any such mechanism would have to hook into
'move-frame-functions', call 'set-frame-window-state-change' and act
accordingly the next time 'window-state-change-functions' is run.

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

I'd use a child frame for that purpose which means that frame movement
won't affect it at all.  And act accordingly when the size of the echo
area changes.

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

'move-frame-functions' should trigger 'window-state-change-functions' via
'set-frame-window-state-change' as sketched above.  Moving or resizing a
frame by dragging its decorations with the mouse is way too noisy - our
redisplay engine would not have the slightest chance to catch up with
it.  Note that our C code even drops the corresponding events when there
are too many so Lisp code wouldn't even see them in the first place.

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

It's rare but when it happens it puts a high stress on the internals of
any application.

martin

Previous Next

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