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

[martin rudalics]

> I somehow forgot we had that problem with GTK builds.

It's the problem that sparked this thread.

> 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?  Can you re-enlarge a child frame
once you have shrunk it?  Does making the initial child frame very large
give you more room to move?

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

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

>> Maybe tumashu can check with a version that uses
>> 'x-set-frame-size-and-position' whether it's still too slow on non-GTK
>> builds.
>
> I'd welcome such a test, yes.

tumashu, if you have any questions, please ask.


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.

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

martin

frame-size-history.diff
Description: Text Data