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

[Dmitry Gutov]

On 14.01.2020 18:50, martin rudalics wrote:

> Run it under gdb with a breakpoint like
>
> break gtkutil.c:1004
>
> and continue until it is hit by tumashu's 'resize-test' invocation.
> Then do p totalwidth and p totalheight (here they are 390 and 360).

Will do, tomorrow.

>  > And so far, my only guess is: GNOME doesn't resize non-decorated 
> windows. Or our code doesn't. Because set-frame-size likewise fails for 
> fullscreen (or even half-screen) windows, and they lack most of the 
> decorations as well (aside from one window border).
>
> That's easy to check: Just create a new undecorated, non-child frame and
> see whether you can resize it.

Any code I can try?

> These look fishy to me.  Here the resized child frame has
>
> ((outer-position 55 . 141)
>   (outer-size 390 . 402)
>   (external-border-size 0 . 0)
>   (outer-border-width . 0)
>   (title-bar-size 0 . 0)
>   (menu-bar-external . t)
>   (menu-bar-size 0 . 0)
>   (tab-bar-size 0 . 0)
>   (tool-bar-external . t)
>   (tool-bar-position . top)
>   (tool-bar-size 390 . 42)
>   (internal-border-width . 0))
>
> I doubt that at a position of 2037 much resizing can be done.  In either
> case, the outer height of your child frame _has_ changed from 360 to 720
> or at least 'frame-geometry' is told so.

When I created it with the appropriate size, frame-geometry reflected 
it, yes.

> What position do you get when
> you put the child frame at (0, 0) of its parent?

((outer-position 1987 . 50)
 (outer-size 736 . 390)
 (external-border-size 0 . 0)
 (outer-border-width . 0)
 (title-bar-size 0 . 0)
 (menu-bar-external . t)
 (menu-bar-size 0 . 0)
 (tab-bar-size 0 . 0)
 (tool-bar-external . t)
 (tool-bar-position . top)
 (tool-bar-size 0 . 0)
 (internal-border-width . 0))

> Is yours by chance a
> high-resolution display?

Yes, HiDPI. 3840x2160. And I also moved the window to the right side of 
the screen for convenience. So the numbers should be right, and there's 
certainly enough space for the child frame to be resized (it's much 
smaller than the parent frame).

>  >> - Can you reproduce Bug#38452?
>  >
>  > Yes. Every evaluation of the form in the first message shifts a 
> simple, non-maximized frame a bit up-left by (24 . 22).
>
> Maybe that's the core of our problem.  Either mutter doesn't want to
> put the frame where Emacs asks to put it or we don't understand where
> mutter has put it.

But that other bug report is about positioning, isn't it? And this 
discussion is about resizing.