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

[martin rudalics]

 the arguments we pass to gtk_window_resize (around line 1004 of
>>    xg_frame_set_char_size in gtkutil.c) OK in your opinion?
>
> Umm, I'd really have to study the code to answer. I don't know this part of 
Emacs at all.
>
> Or do you want be to run it in debugger?

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

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

>> - What does (frame-geometry) return for the frame before and after the
>>    failed resizing attempt?
>
> It's unchanged, and returns e.g.
>
> ((outer-position 2037 . 183)
>   (outer-size 768 . 360)
[...]
>> - What does (frame-geometry) return when you create that child frame
>>    right away with the parameters it should have after resizing?
>
> ((outer-position 2037 . 183)
>   (outer-size 768 . 720)
[...]

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.  What position do you get when
you put the child frame at (0, 0) of its parent?  Is yours by chance a
high-resolution display?

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

martin