* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk @ 2022-02-05 8:50 Augusto Stoffel 2022-02-06 0:59 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 17+ messages in thread From: Augusto Stoffel @ 2022-02-05 8:50 UTC (permalink / raw) To: 53793 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' ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk 2022-02-05 8:50 bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk Augusto Stoffel @ 2022-02-06 0:59 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors [not found] ` <875ypspe4n.fsf@gmail.com> 0 siblings, 1 reply; 17+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-06 0:59 UTC (permalink / raw) To: Augusto Stoffel; +Cc: 53793 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <875ypspe4n.fsf@gmail.com>]
* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk [not found] ` <875ypspe4n.fsf@gmail.com> @ 2022-02-06 9:38 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-02-06 10:02 ` Augusto Stoffel 2022-02-06 14:02 ` Stephen Berman 0 siblings, 2 replies; 17+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-06 9:38 UTC (permalink / raw) To: Augusto Stoffel; +Cc: 53793-done (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))))) ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk 2022-02-06 9:38 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-06 10:02 ` Augusto Stoffel 2022-02-06 14:02 ` Stephen Berman 1 sibling, 0 replies; 17+ messages in thread From: Augusto Stoffel @ 2022-02-06 10:02 UTC (permalink / raw) To: Po Lu; +Cc: 53793-done 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))))) ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk 2022-02-06 9:38 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-02-06 10:02 ` Augusto Stoffel @ 2022-02-06 14:02 ` Stephen Berman 2022-02-07 1:23 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 1 sibling, 1 reply; 17+ messages in thread From: Stephen Berman @ 2022-02-06 14:02 UTC (permalink / raw) To: 53793; +Cc: luangruo, arstoffel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk 2022-02-06 14:02 ` Stephen Berman @ 2022-02-07 1:23 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-02-07 19:33 ` Augusto Stoffel 2022-02-07 22:33 ` Stephen Berman 0 siblings, 2 replies; 17+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-07 1:23 UTC (permalink / raw) To: Stephen Berman; +Cc: arstoffel, 53793 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk 2022-02-07 1:23 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-07 19:33 ` Augusto Stoffel 2022-02-08 0:53 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-02-08 8:56 ` martin rudalics 2022-02-07 22:33 ` Stephen Berman 1 sibling, 2 replies; 17+ messages in thread From: Augusto Stoffel @ 2022-02-07 19:33 UTC (permalink / raw) To: Po Lu; +Cc: Stephen Berman, 53793 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk 2022-02-07 19:33 ` Augusto Stoffel @ 2022-02-08 0:53 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-02-08 8:56 ` martin rudalics 1 sibling, 0 replies; 17+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-08 0:53 UTC (permalink / raw) To: Augusto Stoffel; +Cc: Stephen Berman, 53793 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk 2022-02-07 19:33 ` Augusto Stoffel 2022-02-08 0:53 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-08 8:56 ` martin rudalics 2022-02-09 8:20 ` Augusto Stoffel 1 sibling, 1 reply; 17+ messages in thread From: martin rudalics @ 2022-02-08 8:56 UTC (permalink / raw) To: Augusto Stoffel, Po Lu; +Cc: Stephen Berman, 53793 > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk 2022-02-08 8:56 ` martin rudalics @ 2022-02-09 8:20 ` Augusto Stoffel 2022-02-09 8:45 ` martin rudalics 0 siblings, 1 reply; 17+ messages in thread From: Augusto Stoffel @ 2022-02-09 8:20 UTC (permalink / raw) To: martin rudalics; +Cc: Po Lu, Stephen Berman, 53793 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk 2022-02-09 8:20 ` Augusto Stoffel @ 2022-02-09 8:45 ` martin rudalics 2022-02-09 13:35 ` Augusto Stoffel 0 siblings, 1 reply; 17+ messages in thread From: martin rudalics @ 2022-02-09 8:45 UTC (permalink / raw) To: Augusto Stoffel; +Cc: Po Lu, Stephen Berman, 53793 > (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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk 2022-02-09 8:45 ` martin rudalics @ 2022-02-09 13:35 ` Augusto Stoffel 2022-02-09 18:25 ` martin rudalics 0 siblings, 1 reply; 17+ messages in thread From: Augusto Stoffel @ 2022-02-09 13:35 UTC (permalink / raw) To: martin rudalics; +Cc: Po Lu, Stephen Berman, 53793 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk 2022-02-09 13:35 ` Augusto Stoffel @ 2022-02-09 18:25 ` martin rudalics 2022-02-10 7:43 ` Augusto Stoffel 0 siblings, 1 reply; 17+ messages in thread From: martin rudalics @ 2022-02-09 18:25 UTC (permalink / raw) To: Augusto Stoffel; +Cc: Po Lu, Stephen Berman, 53793 >> '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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk 2022-02-09 18:25 ` martin rudalics @ 2022-02-10 7:43 ` Augusto Stoffel 0 siblings, 0 replies; 17+ messages in thread From: Augusto Stoffel @ 2022-02-10 7:43 UTC (permalink / raw) To: martin rudalics; +Cc: Po Lu, Stephen Berman, 53793 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk 2022-02-07 1:23 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-02-07 19:33 ` Augusto Stoffel @ 2022-02-07 22:33 ` Stephen Berman 2022-02-08 0:53 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 1 sibling, 1 reply; 17+ messages in thread From: Stephen Berman @ 2022-02-07 22:33 UTC (permalink / raw) To: Po Lu; +Cc: 53793, arstoffel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk 2022-02-07 22:33 ` Stephen Berman @ 2022-02-08 0:53 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-02-08 10:24 ` Stephen Berman 0 siblings, 1 reply; 17+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-08 0:53 UTC (permalink / raw) To: Stephen Berman; +Cc: arstoffel, 53793 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk 2022-02-08 0:53 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-08 10:24 ` Stephen Berman 0 siblings, 0 replies; 17+ messages in thread From: Stephen Berman @ 2022-02-08 10:24 UTC (permalink / raw) To: Po Lu; +Cc: 53793, arstoffel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2022-02-10 7:43 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-05 8:50 bug#53793: 29.0.50; 'fullscreen' frame parameter on pgtk Augusto Stoffel
2022-02-06 0:59 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <875ypspe4n.fsf@gmail.com>
2022-02-06 9:38 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-06 10:02 ` Augusto Stoffel
2022-02-06 14:02 ` Stephen Berman
2022-02-07 1:23 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-07 19:33 ` Augusto Stoffel
2022-02-08 0:53 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-08 8:56 ` martin rudalics
2022-02-09 8:20 ` Augusto Stoffel
2022-02-09 8:45 ` martin rudalics
2022-02-09 13:35 ` Augusto Stoffel
2022-02-09 18:25 ` martin rudalics
2022-02-10 7:43 ` Augusto Stoffel
2022-02-07 22:33 ` Stephen Berman
2022-02-08 0:53 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-08 10:24 ` Stephen Berman
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).