bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

[Augusto Stoffel]

On Emacs compiled with pgtk, (frame-parameter nil 'fullscreen) returns
nil when the frame is maximized.  (Without pgtk, it returns the symbol
'maximized'; if I make the frame fullscreen, then the above always
returns the usual 'fullboth'.)

I'm using Gnome on Wayland.  More system information below:

In GNU Emacs 29.0.50 (build 15, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
 of 2022-02-04 built on toolbox
Repository revision: 3e20a900195cb72e4c940db9ff123c3049483074
Repository branch: master
System Description: Fedora Linux 35 (Workstation Edition)

Configured using:
 'configure --with-pgtk'

bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Augusto Stoffel <arstoffel@gmail.com> writes:

> On Emacs compiled with pgtk, (frame-parameter nil 'fullscreen) returns
> nil when the frame is maximized.  (Without pgtk, it returns the symbol
> 'maximized'; if I make the frame fullscreen, then the above always
> returns the usual 'fullboth'.)
>
> I'm using Gnome on Wayland.  More system information below:
>
> In GNU Emacs 29.0.50 (build 15, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
>  of 2022-02-04 built on toolbox
> Repository revision: 3e20a900195cb72e4c940db9ff123c3049483074
> Repository branch: master
> System Description: Fedora Linux 35 (Workstation Edition)
>
> Configured using:
>  'configure --with-pgtk'

Should be fixed now, thanks.

bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

(When replying to bug reports in the future, please use "Reply to All",
so that your messages can be recorded by the bug tracker.)

Augusto Stoffel <arstoffel@gmail.com> writes:

> Yes, the frame parameter is correctly reported now, thanks!

I'm closing this bug then, thanks.

> It also seems that `move-frame-functions' are not run as promised.  Or
> at least the following bit of configuration is still broken on pgtk but
> works fine on X.

If you're running Wayland, then it's a limitation of the Wayland
protocol, which has no global coordinate system.  GTK exposes it as
every Wayland window (surface) being placed at 0, 0.

>     (add-hook 'move-frame-functions
>               (lambda (frame) "Undecorate frame when maximized."
>                 (set-frame-parameter frame 'undecorated
>                  (eq 'maximized (frame-parameter frame 'fullscreen)))))

bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

[Augusto Stoffel]

On Sun,  6 Feb 2022 at 17:38, Po Lu <luangruo@yahoo.com> wrote:

> (When replying to bug reports in the future, please use "Reply to All",
> so that your messages can be recorded by the bug tracker.)

Oops, sorry.

> Augusto Stoffel <arstoffel@gmail.com> writes:
>
>> Yes, the frame parameter is correctly reported now, thanks!
>
> I'm closing this bug then, thanks.
>
>> It also seems that `move-frame-functions' are not run as promised.  Or
>> at least the following bit of configuration is still broken on pgtk but
>> works fine on X.
>
> If you're running Wayland, then it's a limitation of the Wayland
> protocol, which has no global coordinate system.  GTK exposes it as
> every Wayland window (surface) being placed at 0, 0.

I see.  Apparently there's no hook to run when a frame is resized, which
would be useful as well.  Maybe a new variable is unnecessary, and
`move-frame-functions' should be run also when moving the bottom right
corner of the frame.

>>     (add-hook 'move-frame-functions
>>               (lambda (frame) "Undecorate frame when maximized."
>>                 (set-frame-parameter frame 'undecorated
>>                  (eq 'maximized (frame-parameter frame 'fullscreen)))))

bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

[Stephen Berman]

On Sun, 06 Feb 2022 17:38:14 +0800 Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> wrote:

> (When replying to bug reports in the future, please use "Reply to All",
> so that your messages can be recorded by the bug tracker.)
>
> Augusto Stoffel <arstoffel@gmail.com> writes:
>
>> Yes, the frame parameter is correctly reported now, thanks!
>
> I'm closing this bug then, thanks.
>
>> It also seems that `move-frame-functions' are not run as promised.  Or
>> at least the following bit of configuration is still broken on pgtk but
>> works fine on X.
>
> If you're running Wayland, then it's a limitation of the Wayland
> protocol, which has no global coordinate system.  GTK exposes it as
> every Wayland window (surface) being placed at 0, 0.

This sounds similar to bug#52697, but I'm not running Wayland (I think;
how can I know for sure?).  Is there some way to programmatically get
the real screen coordinates in the PGTK build?

Steve Berman

bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> This sounds similar to bug#52697, but I'm not running Wayland (I think;
> how can I know for sure?).

Evaluate (pgtk-backend-display-class); it should return
"GdkWaylandDisplay" on Wayland.

> Is there some way to programmatically get the real screen coordinates
> in the PGTK build?

No, since Wayland doesn't have a concept of "real screen coordinates" at
all.

Thanks.

bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

[Augusto Stoffel]

Hi Po Lu,

I don't mean to nag you, but I think you missed my last message from
yesterday and I'm curious as to what you would say.  I'll just repeat my
point here:

Unless I'm missing something, there is no hook run when the frame is
resized.  Shouldn't there be one?  It might make sense to just use
`move-frame-functions' for this as well; after all, this hook already
runs if I resize the frame from any corner other than the bottom right
one.

bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

[Stephen Berman]

On Mon, 07 Feb 2022 09:23:02 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> This sounds similar to bug#52697, but I'm not running Wayland (I think;
>> how can I know for sure?).
>
> Evaluate (pgtk-backend-display-class); it should return
> "GdkWaylandDisplay" on Wayland.

Thanks, that returns "GdkX11Display", confirming I'm not running Wayland.

>> Is there some way to programmatically get the real screen coordinates
>> in the PGTK build?
>
> No, since Wayland doesn't have a concept of "real screen coordinates" at
> all.

But since I'm not running Wayland, is there some way under X11?  (Maybe
it would be better if you answer this question in bug#52697, since my
conjecture that that bug is related to the one in this thread is
apparently wrong.)

Steve Berman

bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Augusto Stoffel <arstoffel@gmail.com> writes:

> I don't mean to nag you, but I think you missed my last message from
> yesterday and I'm curious as to what you would say.  I'll just repeat my
> point here:

It probably got caught up in the spam filter, sorry.

> Unless I'm missing something, there is no hook run when the frame is
> resized.  Shouldn't there be one?  It might make sense to just use
> `move-frame-functions' for this as well; after all, this hook already
> runs if I resize the frame from any corner other than the bottom right
> one.

I don't know if we already have something like that, so maybe try asking
on help-gnu-emacs first.  Thanks.

bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> Thanks, that returns "GdkX11Display", confirming I'm not running Wayland.

> But since I'm not running Wayland, is there some way under X11?  (Maybe
> it would be better if you answer this question in bug#52697, since my
> conjecture that that bug is related to the one in this thread is
> apparently wrong.)

That's an unrelated bug, which I'll look into in the coming days.
Thanks.

bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

[martin rudalics]

 > Unless I'm missing something, there is no hook run when the frame is
 > resized.  Shouldn't there be one?

Try 'window-size-change-functions'.

martin

bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

[Stephen Berman]

On Tue, 08 Feb 2022 08:53:44 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> Thanks, that returns "GdkX11Display", confirming I'm not running Wayland.
>
>> But since I'm not running Wayland, is there some way under X11?  (Maybe
>> it would be better if you answer this question in bug#52697, since my
>> conjecture that that bug is related to the one in this thread is
>> apparently wrong.)
>
> That's an unrelated bug, which I'll look into in the coming days.

Thanks.

Steve Berman

bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

[Augusto Stoffel]

On Tue,  8 Feb 2022 at 09:56, martin rudalics <rudalics@gmx.at> wrote:

>> Unless I'm missing something, there is no hook run when the frame is
>> resized.  Shouldn't there be one?
>
> Try 'window-size-change-functions'.

All right, that should do the job, thanks.

(But I still think it would be nice – and reduce confusion – to extend
`move-frame-functions'.)

>
> martin

bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

[martin rudalics]

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

To catch resizing 'move-frame-functions' is much too noisy.

martin

bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

[Augusto Stoffel]

On Wed,  9 Feb 2022 at 09:45, martin rudalics <rudalics@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

bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk

[martin rudalics]

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

[Augusto Stoffel]

On Wed,  9 Feb 2022 at 19:25, martin rudalics <rudalics@gmx.at> wrote:

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

It's very hard to see that this is the intended usage just from the
documentation, thanks for explaining.

Normally, resizing Emacs is quantized by character, but this assumption
is not always true.  For instance, in Gnome, if I tile Emacs and my web
browser side by side (with S-<left> and S-<right>) and then drag the
boundary between the two windows, the Emacs frame is resized pixel by
pixel (and there are visual glitches, indeed).  So someone might still
one day need want some optimization you describe above for the resize
case as well.  But everything is fine by me.