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

[Dmitry Gutov <dgutov@yandex.ru>]

On 31.01.2020 18:44, martin rudalics wrote:
>  > Considering scaling was only a problem for GTK, that doesn't sound
>  > like success. Anyway, resizing normal undecorated frames in GTK seems
>  > to work just as well now. Resizing child frame (with scaling on) is
>  > still broken (but looks a bit different, no jumping around, at least).
> 
> Presumably resizing child frames is still broken with scaling off too.

I somehow forgot we had that problem with GTK builds. There is a change:

I can now resize a child frame with the mouse to a size *smaller* than 
it was originally. As well as move its top-left corner, within certain 
parameters. Further than that, either Emacs stops me, or the right (or 
bottom, or both) border hides from view.

>  > With GTK build frame resizing also doesn't honor non-pixelwise
>  > resizing. When frame-resize-pixelwise is nil, resizing routinely eats
>  > into internal borders (right and bottom ones).
> 
> Right.  I'll attach a patch that fixes it. 

That seems fixed, thank you.

> Maybe we'll have to
> investigate the size hints issue next.  The whole emacsgtkfixed.c stuff
> (which I do not understand) troubles me considerably.  Could you try
> building with GTK 2?

Done that.

The GTK 2 build seems all-around fine, with almost none of the issues 
described in this thread: child frames both move and resize fine.

It works fine with scaling aside from thin scrollbars and small toolbar 
icons (Lucid has basically the same issues).

It has similar mouse-resizing problems with undecorated frames, but your 
recent patch seems to have fixed that as well.

So I think we could recommend using it as the workaround.

>  >> (benchmark 1 `(x-set-frame-size-and-position ,test-frame nil nil 50 
> 50))
>  >>
>  >> => 0.100523s
>  >
>  > Seems like a possible improvement, but still much slower than 
> set-frame-position with the GTK build.
> 
> Neither of these benchmarks seems meaningful in the first place.  What
> would it measure?

The seemingly slowest part of operations "show popup" and "reposition 
popup". FWIW, it certain situations a popup will have to be repositioned 
every time the user types something.

> Maybe tumashu can check with a version that uses
> 'x-set-frame-size-and-position' whether it's still too slow on non-GTK
> builds.

I'd welcome such a test, yes.