[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: Thu, 30 Jan 2020 05:10:26 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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).

reply via email to

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