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

[Dmitry Gutov]

On 28.01.2020 12:47, martin rudalics wrote:
>  >> The reason for this (and I don't know if you've seen it as well)
>  >
>  > Not really. If I drag any border of a normal, decorated frame, the 
> other borders stay where they were.
>
> Did you run this with a pristine, unpatched GTK+ build?  Did you compare
> the outer right edges before and after the moves?  Everything here is OK
> when running the 'bar' functions from a Lucid build, BTW.

Unpatched GTK+ build, yes. Or any other build. Resizing the "normal" 
kind of frames always behaves as expected here. Moving by the title-bar 
does, too. It might be not buttery-smooth, but the edges always move 
where expected, and there are no unexpected jumps that I see when 
resizing an undecorated frame. Or move a frame by the mode-line in a 
Lucid build.

I didn't exactly compare the edge positions programmatically, but my 
eyes are usually good at catching that kind of thing.

> I suppose though that your Emacs' redraws too lag behind by showing
> either a gap between the right scroll bar and frame border when dragging
> to the left and not showing the scroll bar when dragging to the right?
> Here they do that even when dragging the left border with the WM alone.

That happens here too.

And it's not what my previous complaints were about. A drift is not 
simply a lag. Lag rights itself at the end of the cursor motion (you 
just have to wait a little). Drift doesn't right itself: the cursor ends 
up at a certain distance from the the point of the frame it has been 
dragging.

>  > I'm guessing that here, under Mutter, the window manager controls the
>  > sizing and positioning when I'm doing this. And Emacs just handles
>  > sizing notifications and redraws itself. So I've never seen this
>  > particular issue act up in practice.
>
> Then it would ignore the Emacs sizing request even for a top-level frame
> something we hadn't that far.  Unless your machine is so fast that you
> can handle all requests in "real time" so that you don't see the lags I
> mentioned above.

It doesn't exactly ignore sizing requests. Or not all of them. At least, 
set-frame-size works just fine on top-level frames like that.

Rather, I think in these cases it's not Emacs which handles the resizing 
or dragging events. The WM does that and only tells the Emacs window to 
resize appropriately.

>  > But your description sounds similar to my results in the previous 
> experiment with non-decorated non-child frames.
>  >
>  >> The commands 'foo-' and 'foo+' drag the left border a 100 times to the
>  >> right or left by three pixels in one step.  The right border should
>  >> remain unchanged.  The commands 'bar-' and 'bar+' should do the same
>  >> but, in fact, sometimes move the right border as well.
>  >
>  > Yes, I'm seeing exactly the same results with these commands (aside 
> from the redisplay detail, which I haven't tried).
>
> You mean the right border never ever moves with the bar functions.

I'm saying I see the same results are you do (with Mutter; GTK3 build).

foo commands don't move the right border. bar commands do move it 
(basically always).