[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: Dmitry Gutov
Subject: Re: Emacs's set-frame-size can not work well with gnome-shell?
Date: Sun, 16 Feb 2020 00:31:40 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 14.02.2020 10:48, martin rudalics wrote:
 > Sounds like posframe could make this work if both patches could be
 > pushed to emacs-27, and if they didn't break any other window
 > managers.

We could add another variable to control the behavior of the
use_gdk_resize variant.  It's a really awful hack in either case,

> (Hiding the child frame during resizing could be used only when resizing down from the unreasolable large size, for example).

"down"?  Conceptually, the patches are mutually exclusive.  I don't know
whether it's possible to reconcile them the way you sketch above.

Hmm, I think I see now.

But anyway, the second patch is equivalent to my workaround (hiding/showing the frame), so it doesn't seem strictly necessary. The downside is the same: flickering. I guess the only part that could be improved there is to avoid resizing (and flicker) if the target size stays the same.

Another thing: judging by the file names, at least, that change in the behavior would also affect the gtk2 build. But it's already working fine. We certainly don't want to introduce flickering on resize to it.

> BTW, are they supposed to be applied on top of current emacs-27? The second one fails with:
 > $ patch -p1 < hide-child-frame-during-resize.diff
 > patching file src/gtkutil.c
 > Hunk #2 FAILED at 1002.
 > Hunk #3 succeeded at 1018 (offset 1 line).
 > 1 out of 3 hunks FAILED -- saving rejects to file src/gtkutil.c.rej
 > patching file src/xterm.c
 > Hunk #1 succeeded at 13763 (offset 16 lines).

They apply here properly against latest Emacs 27 (using git apply) but
_not_ on top of each other.

Both patches are based on your earlier observations.  I have not found
out anything new in this area.

To clarify: would you consider the patch #1 for inclusion in Emacs 27?

I rather hate flickering, so #2 seems out of the question, IMHO.

Perhaps you (and maybe someone else)
could try to run either of them for a while and tell us whether they
render the overall behavior unbearable.  Also, I have no idea whether
any kind of eventual unmapping or hiding a child frame may render
further enlargings impossible again.  In particular, I don't know who
stores that "initial" frame size someone uses to compare the requested
frame size against and refuses to grant the request when the latter is

We're going to ask the Mutter developers.

reply via email to

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