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

[Dmitry Gutov <dgutov@yandex.ru>]

[-- Attachment #1: Type: text/plain, Size: 2949 bytes --]

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 #2: Screenshot from 2020-02-24 02-05-36.png --]
[-- Type: image/png, Size: 299843 bytes --]