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

[Dmitry Gutov]

On 01.02.2020 12:35, martin rudalics wrote:
>  > I somehow forgot we had that problem with GTK builds.
>
> It's the problem that sparked this thread.

Yes, of course.

>  > There is a change:
>  >
>  > I can now resize a child frame with the mouse to a size *smaller* than
>  > it was originally. As well as move its top-left corner, within certain
>  > parameters. Further than that, either Emacs stops me, or the right (or
>  > bottom, or both) border hides from view.
>
> This hints at some ill max_width and/or max_height size hints.  Are
> both, width and height, constrained?

Yes.

> Can you re-enlarge a child frame
> once you have shrunk it?

Yes, but only within the original bounds.

> Does making the initial child frame very large
> give you more room to move?

Yes, as per the above.

>  > The GTK 2 build seems all-around fine, with almost none of the issues 
> described in this thread: child frames both move and resize fine.
>  >
>  > It works fine with scaling aside from thin scrollbars and small 
> toolbar icons (Lucid has basically the same issues).
>
> We should be able to fix these - after all, some people still build with
> GTK 2.

Sounds good, but IME GTK2 applications don't work well with scaling. So 
maybe leave it alone unless it's really easy to do.

>  > It has similar mouse-resizing problems with undecorated frames, but 
> your recent patch seems to have fixed that as well.
>  >
>  > So I think we could recommend using it as the workaround.
>
> "One" workaround, hopefully.

The one all-around good one, so far.

>  > The seemingly slowest part of operations "show popup" and "reposition
>  > popup". FWIW, it certain situations a popup will have to be
>  > repositioned every time the user types something.
>
> It will neither measure the time Emacs needs for redrawing the popup nor
> the time for exposing the part of the parent frame that gets revealed.

It measures one bottleneck. But, of course, there can be other ones.

> Meanwhile, let's try to proceed on two axes:
>
> (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 made it go back to the previous stage of 
affairs (resizing is limited by the original child frame bounds).

> (2) Look into the size hints issue.  I suspect that what we see here is
> Bug#8919 raising its ugly head again.  To fix that bug, Jan has
> rewritten XSetWMNormalHints to use his XSetWMSizeHints from
> emacsgtkfixed.c, which is a gross hack in a dual sense: It (i) replaces
> an X function (ii) for the purpose of fixing the behavior of a gtk
> function.
>
> Let's try the following.  Apply the attached frame-size-history.diff
> from a pristine repository.  Then start with 'test-frame' created, eval
> the following forms (positions and sizes may need adapting)
>
> (setq frame-size-history '(100))
> (x-set-frame-size-and-position test-frame 400 200 100 50)
> (frame--size-history test-frame)
> (display-buffer "*frame-size-history*")
>
> and post the history here (unless your Emacs crashed before).

No crash. Does this look right?

Frame size history of #<frame test child-frame 0x55ebb491a630>
x-set-frame-size-and-position-1  (720 360 448 200) nil
x-set-frame-size-and-position-3  (720 360 400 200) nil

The child frame got resized to a smaller size, though.

Should I try a bigger width and height? The history looks pretty much 
the same in that case.