[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs's set-frame-size can not work well with gnome-shell?

From: martin rudalics
Subject: Re: Emacs's set-frame-size can not work well with gnome-shell?
Date: Fri, 13 Mar 2020 18:46:19 +0100

> With a custom var, you mean. OK.

I attach the latest diff I made for Emacs 27.  The variable is called
'x-gtk-resize-child-frames' and may assume the values 'hide' and
'resize-mode' in addition to the default nil.  It should work for Emacs
28 as well but it would be important to test it on Emacs 27 for obvious

Clearly, people might want to to set 'x-wait-for-event-timeout' to zero
as well and we should tell them so.  But here I can't observe that doing
so has any impact.

> IIUC though, the majority of the GTK developers work on GNOME and
> Mutter as well. If that's the case, asking for Mutter's developers'
> help makes sense anyway.

It would make sense but if they don't respond ...

> I asked that question today. Got one +1 so far: 

Not much so far.  In either case, whenever people report a "it changes
size somewhat half a second later" then this usually means that a frame
move occurred on a platform (like GNOME shell) that does not report a
frame position as Emacs expects it (Bug#38452), does not send a suitable
event in due time and is thereafter penalized by xterm.c's

  /* As a last resort, just wait 0.5 seconds and hope that XGetGeometry
     will then return up-to-date position info. */

  wait_reading_process_output (0, 500000000, 0, false, Qnil, NULL, 0);

This should be bypassed by my patch but for non-child frames the delay
persists.  Users then might want to drop a couple of zeros from that
insane nanosecond argument.


Attachment: x-gtk-resize-child-frames.diff
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]