[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: Mon, 24 Feb 2020 02:11:44 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 21.02.2020 18:08, martin rudalics wrote:

With the patch applied and 'x-resize-child-frame-special' non-nil
'x-create-frame' asks for an initial frame size of 1000x1000 pixels

   if (FRAME_PARENT_FRAME (f) && x_resize_child_frame_special)
     adjust_frame_size (f, 1000, 1000, 0, true, Qx_create_frame_2);

So what you see could be the 1000 (2000 scaled?) pixels from that call.

Yes, (frame-geometry test-frame) includes (1048 . 1000) as outer-size.

But I would expect this initial size to be only assigned briefly and then changed (by Emacs, internally, without having been asked) to the dimensions originally specified by the caller. So that the workaround is applied, but the user doesn't really have to see it.

The child frame could even be made invisible while it's created with this huge size, before it's resized to the target size.

You could try with other values instead of 1000 so we can tell whether
that call has any visible impact.  It's possible that the WM rejects too
large values, for example, because they would exceed the initial size of
the parent frame (insanely large values can make Emacs even crash here).

Seems to be not the issue here.

And always keep in mind that all this is a crazy hack that tries to
second-guess what the WM (or GTK) might do.  I've nowhere in their code
seen the slightest evidence for such behavior.

 > Otherwise, it seems to work OK is the test scenario. Not so ideal in
 > "production": it seems company-posframe still fails to change the
 > width (!) when height is kept unchanged. And when that happens, the
 > expected extra area (when we're enlarging the frame, but seemingly
 > fail) is apparently where Emacs and the WM disagree (clicks don't do
 > through).

Did you use 'set-frame-width' to change it?

posframe--set-frame-size always delegates to fit-frame-to-buffer. Which calls modify-frame-parameters at the end.

> Does it also fail to shrink
> the width or only to enlarge it?

As I describe at the end of this email, the last patch is kinda broken.

I went to the previous version of x-resize-child-frame-special.diff and this time couldn't reproduce this effect (of width often staying unchanged). The problem of "first size changes, then contents" is still there. I also saw occasional graphical glitches and window update problems like the one in the attached screenshot (see the black area; the first line, in blue, should have not have been wrapped in two). Those were hard to reproduce reliably, however.

In either case I attach a patch that now tries to make the second
adjust_frame_size call apply the initially requested sizes but I'm
afraid that it will not produce anything useful.

If you're saying it should do what I described above... it does not. :-(

Also, the test scenario (one that calls (set-frame-height frame 20)) made it 3 lines tall from the POW of Emacs (but not the WM).

Attachment: Screenshot from 2020-02-24 02-05-36.png
Description: PNG image

reply via email to

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