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

[Dmitry Gutov <dgutov@yandex.ru>]

On 05.02.2020 12:15, martin rudalics wrote:
>  >> Does making the initial child frame very large
>  >> give you more room to move?
>  >
>  > Yes, as per the above.
> 
> So you could make the initial child frame 10000 pixel wide and high and
> resizing would never fail?

Seems like it.

But set-frame-size still does nothing, so I wouldn't know how to take 
advantage of this discovery programmatically.

>  >> (1) Pursue the previous idea to use X calls instead of gtk calls for
>  >> resizing child frames.  For this purpose, on top of mouse+xfns.diff
>  >> please change the
>  >>
>  >>      gdk_window_move_resize
>  >>        (window, left / scale, top / scale, new_pixel_width / scale,
>  >>         new_pixel_height / scale);
>  >>
>  >> call to
>  >>
>  >>        if (FRAME_PARENT_FRAME (f))
>  >>      XMoveResizeWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
>  >>                 left / scale, top / scale, new_pixel_width / scale,
>  >>                 new_pixel_height / scale);
>  >>        else
>  >>      gdk_window_move_resize
>  >>        (window, left / scale, top / scale, new_pixel_width / scale,
>  >>         new_pixel_height / scale);
>  >>
>  >> If this works but gives problem with scaling, then drop all " / scale"
>  >> instances in the XMoveResizeWindow call.
>  >
>  > Didn't help. The patch, as-is, introduced a scaling problem. And
>  > dropping "/ scale" instances
> 
> Which ones did you drop - all?  The ones in the gdk_window_move_resize
> call should remain, only the ones from the XMoveResizeWindow call should
> be dropped.

Only the ones from the XMoveResizeWindow call.

> I meanwhile installed mutter here.  Debian apparently doesn't resolve
> the dependencies well so I had to manually install some additional
> gnomish features.  The whole thing still looks incomplete though.

Sounds like trying a Live CD might work better for you. That leaves the 
question of how to get an Emacs build on there, though.

> The frame positioning behavior of mutter is a pain for me and renders my
> usual Emacs frame setup practically unusable.  It's possibly a
> consequence of making borders invisible and having the frame minimize
> and maximize when it's pushed against the bottom or top edge of the
> display.  Visible child frames never resize, I cannot even shrink them.
> Also, I can't get vertical scroll bars for them.  In one case I was told
> 
> Window manager warning: Window 0x4a0003d (Terminal) sets an MWM hint 
> indicating it isn't resizable, but sets min size 1 x 1 and max size 
> 2147483647 x 2147483647; this doesn't make much sense.
> 
> but I'm not even sure whether these resulted from an Emacs frame - the
> max size values are not ours AFAICT.  Also we set MWM hints only from
> within non-GTK builds, maybe I've been running one of them.

Sounds like it's talking about the "Terminal" app?

> Anyway, I meanwhile further rewrote the code for mouse dragging and
> 'x-set-frame-size-and-position', patch attached.  I also added an
> interface to the gtk inspector, you can enable it via
> 
> (when (fboundp 'x-gtk-debug)
>    (x-gtk-debug t))
> 
> Maybe you can derive something from running it.  At least here, when
> under "visual" turning on "graphics actualizations", I can clearly see
> that GTK processes and passes on the resize requests for child frames
> (by turning the frame red) and that they are later apparently dismissed
> by mutter.

Will do! Although it sounds like you probably have all the same 
information now.