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

[Dmitry Gutov <dgutov@yandex.ru>]

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,
> though.
> 
>  > (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
> larger.

We're going to ask the Mutter developers.