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

[Robert Pluim <rpluim@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2681 bytes --]

martin rudalics <rudalics@gmx.at> writes:

>>> (modify-frame-parameters nil '((left . 0) (top . 0) (width . 130) (height . 56)))
>>>
>>
>> That does nothing, but the following resizes the frame:
>>
>> (modify-frame-parameters nil '((left . 0) (top . 0) (width . 100) (height . 48)))
>>
>> And has done the right thing:
>>
>> (frame-parameter nil 'height) => 48
>> (frame-parameter nil 'width) => 100
>
> Looks like the missing link.  If your window manager refuses to resize
> the frame, it probably decides that it would not fit on the screen.
> Please increase separately from 48 and 100 till you find the
> problematic value and compare it against your workspace size.
>

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.

>> Good:
>>
>> (frame-pixel-width) => 1849
>> (frame-pixel-height) => 1680
>
> This looks like our bad.  Somehow we decide that the window manager
> will comply and set the values we asked for.  Do these values also
> occur with emacs -Q followed by
>
> (modify-frame-parameters nil '((left . 0) (top . 0) (width . 130) (height . 56)))
>
> I suppose not since otherwise you would have probably told me so.

Yes, I get the same values for frame-pixel-{width,height} if I modify
the frame size after startup. Thatʼs not surprising to me, the issue
is somewhere during the setup of the initial frame.

>>> Can you try with another toolkit or X without any toolkit so we can
>>> tell whether this is GTK or window manager specific?
>>
>> --with-x-toolkit={none,lucid} both work fine (although you can see the
>>    modeline of the frame appear as if it were 80x36, and then it
>>    resizes correctly to 130x56).
>
> This implies that the bug is somewhere in our interception of X
> messages and letting GTK not see them (otherwise GTK should have
> reported an error).  However, it contradicts the assumption that the
> window manager refuses to resize our frame since otherwise it would
> have done so for the Lucid build too.  Rather it seems that GTK itself
> decides that the frame is too large to fit on the screen.  But without
> signalling an error?

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:


[-- Attachment #2: Selection_029.png --]
[-- Type: image/png, Size: 16790 bytes --]

[-- Attachment #3: Type: text/plain, Size: 10 bytes --]



Robert