[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: martin rudalics
Subject: Re: Emacs's set-frame-size can not work well with gnome-shell?
Date: Wed, 5 Feb 2020 10:15:26 +0100

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

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

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

No.  You apparently don't get anything from the XSetWMSizeHints calls.

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.

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.

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.


Attachment: mouse+xfns.diff
Description: Text Data

reply via email to

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