[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: Sat, 1 Feb 2020 01:22:00 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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

I'd welcome such a test, yes.

reply via email to

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