[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: Emacs's set-frame-size can not work well with gnome-shell?
Date: Wed, 5 Feb 2020 04:39:39 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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?


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

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]