[Top][All Lists]

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

bug#31745: 回复: bug#31745: 回复:回复:Re: 回复:bug#31745: Frame's bug whenwindow

From: Robert Pluim
Subject: bug#31745: 回复: bug#31745: 回复:回复:Re: 回复:bug#31745: Frame's bug whenwindow-system
Date: Thu, 28 Jun 2018 16:15:59 +0200

martin rudalics <address@hidden> 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:

PNG image


reply via email to

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