bug#31745: 回复： bug#31745: 回复：回复：Re: 回复：bug#31745: Frame's bug whenwindow-system

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>> 130x56 fits on my screen fine, so Iʼm not sure thatʼs what's
>> happening. Once the initial frame has been created I can modify its
>> size without any problems.
>
> Maybe it does not fit with the initial window position chosen by the
> window manager.
>
>>  Thatʼs not surprising to me, the issue
>> is somewhere during the setup of the initial frame.
>
> Window managers can be more picky to make sure a new frame fits on the
> screen.  For an already existing frame they usually accept that it
> moves off-screen.  Can you position any other application's first
> window off-screen?
>

Iʼve tried eg

xterm -geometry 80x36+-50+-50

but the resulting window is always fully visible. Itʼs possible the
window manager hasn't fully implemented support for negative offsets,
itʼs somewhat obscure.

>> Youʼre right that the frame is not resized the way we requested, but
>> it doesnʼt seem to be because GTK thinks itʼs too big, since eg
>>
>> src/emacs -Q --eval "(setq default-frame-alist '((left . 0) (top . 0) (width 
>> . 79) (height . 35)))"
>>
>> can result in emacs thinking the frame is *smaller* than what's
>> actually displayed, so the modeline is drawn too high, and the
>> minibuffer has empty lines drawn underneath it. Screenshot:
>
> If you continue to work with this frame without (implicitly)
> triggering a frame resize, does Emacs keep on thinking so forever?

Yes.

> Does the buggy behavior trigger also when you do not set the 'left'
> and 'top' parameters, that is, if you purely resize the frame and not
> move it at the same time?  If so, we maybe should try to use
> gdk_window_move_resize or whatever there is now.  ISTR that I tried it
> once and it seemed to work but dropped the idea later because I had
> difficulties figuring out a suitable interface.

src/emacs -Q --eval "(setq default-frame-alist '((width . 79) (height . 35)))"

shows the same behaviour.

> Also, does setting 'x-gtk-use-window-move' change anything?  It could
> conceptually, for GTK 3.18.

Thatʼs set to t by default. Setting it to nil doesnʼt change anything.

Regards

Robert