[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk
From: |
martin rudalics |
Subject: |
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
- bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk, (continued)
- Message not available
- bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk, Po Lu, 2022/02/06
- bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk, Augusto Stoffel, 2022/02/06
- bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk, Stephen Berman, 2022/02/06
- bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk, Po Lu, 2022/02/06
- bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk, Augusto Stoffel, 2022/02/07
- bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk, Po Lu, 2022/02/07
- bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk, martin rudalics, 2022/02/08
- bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk, Augusto Stoffel, 2022/02/09
- bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk, martin rudalics, 2022/02/09
- bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk, Augusto Stoffel, 2022/02/09
- bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk,
martin rudalics <=
- bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk, Augusto Stoffel, 2022/02/10
- bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk, Stephen Berman, 2022/02/07
- bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk, Po Lu, 2022/02/07
- bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk, Stephen Berman, 2022/02/08