[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: martin rudalics
Subject: bug#31745: 回复: bug#31745: 回复:回复:Re: 回复:bug#31745: Frame's bug whenwindow-system
Date: Fri, 29 Jun 2018 10:42:02 +0200

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

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

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.

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


reply via email to

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