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

[martin rudalics]

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

martin

mouse+xfns.diff
Description: Text Data