bug#13512: 24.3.50; Mini-window glitch with GTK

bug#13512: 24.3.50; Mini-window glitch with GTK

[Xue Fuqiao]

On Ubuntu 12.10 with GTK 2.24.13, height of the minibuffer window looks
too large immediately after startup, but shrinks to normal after first
input comes. The problem is easily visible with `emacs -Q', but doesn't
appear with emacs -Q --execute '(tool-bar-mode 0)'.



In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.13)
 of 2013-01-20 on Emacs
Bzr revision: 111567 eggert@cs.ucla.edu-20130119224847-upp58v7tz0rkugsb
Windowing system distributor `The X.Org Foundation', version 11.0.11300000
System Description:	Ubuntu 12.10

Configured using:
 `configure --enable-link-time-optimization --enable-gcc-warnings'

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<menu> r e - e m SPC - <backspace> <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)


-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

bug#13512: 24.3.50; Mini-window glitch with GTK

[Eli Zaretskii]

> Date: Tue, 22 Jan 2013 08:55:31 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: emacs-devel@gnu.org
> 
> On 01/21/2013 09:24 PM, Eli Zaretskii wrote:
> 
> > When it does happen, do you see the frame resize when you type C-x C-f
> > (or something else that causes minibuffer input)?
> 
> The frame is resized by removing extra height from minibuffer window;
> size of main window is not changed and mode line is not moved.

Interesting.  Can you see if change_frame_size is being called at some
point to cause this resizing?

bug#13512: 24.3.50; Mini-window glitch with GTK

[Dmitry Antipov]

On 01/22/2013 12:01 PM, Eli Zaretskii wrote:

> Interesting.  Can you see if change_frame_size is being called at some
> point to cause this resizing?

Yes, it's called.

Dmitry

bug#13512: 24.3.50; Mini-window glitch with GTK

[Eli Zaretskii]

> Date: Tue, 22 Jan 2013 13:44:50 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: Xue Fuqiao <xfq.free@gmail.com>, 13512@debbugs.gnu.org
> 
> On 01/22/2013 12:01 PM, Eli Zaretskii wrote:
> 
> > Interesting.  Can you see if change_frame_size is being called at some
> > point to cause this resizing?
> 
> Yes, it's called.

Thanks.  Next, I'd suggest to look at the backtrace and the parameters
it is called with, and compare that with a non-GTK build where this
problem doesn't happen.

bug#13512: 24.3.50; Mini-window glitch with GTK

[Dmitry Antipov]

On 01/22/2013 03:41 PM, Eli Zaretskii wrote:

> Thanks.  Next, I'd suggest to look at the backtrace and the parameters
> it is called with, and compare that with a non-GTK build where this
> problem doesn't happen.

[adding Jan to CC:]

I'm just curious about this bug's origin. For me, it's GTK3-only issue,
and everything works fine with GTK2; but the original report from Xue
notes GTK2.

I found that the size values returned by gtk_widget_get_preferred_size
in xg_update_tool_bar_sizes are different for GTK3 and GTK2. For GTK2,
width and height are always 47 and 44 pixels; for GTK3, it's 37x36 for
the first call to xg_update_tool_bar_size and 43x44 for the subsequent
calls. Visually the toolbar size doesn't change and it looks the same
between GTK2 and GTK3.

Finally, this seems to be a question for Jan: GTK3 docs says that the
handle box widget is obsolete (http://developer.gnome.org/gtk3/stable/GtkHandleBox.html),
so why we prefer it for both GTK2 and GTK3?

Dmitry

bug#13512: 24.3.50; Mini-window glitch with GTK

[Jan Djärv]

Hello.

22 jan 2013 kl. 15:55 skrev Dmitry Antipov <dmantipov@yandex.ru>:

> Finally, this seems to be a question for Jan: GTK3 docs says that the
> handle box widget is obsolete (http://developer.gnome.org/gtk3/stable/GtkHandleBox.html),
> so why we prefer it for both GTK2 and GTK3?

Why not?  Its been there from the start.

	Jan D.

bug#13512: 24.3.50; Mini-window glitch with GTK

[Jan Djärv]

Hello.

This has been fixed in the trunk.

	Jan D.

22 jan 2013 kl. 15:55 skrev Dmitry Antipov <dmantipov@yandex.ru>:

> On 01/22/2013 03:41 PM, Eli Zaretskii wrote:
> 
>> Thanks.  Next, I'd suggest to look at the backtrace and the parameters
>> it is called with, and compare that with a non-GTK build where this
>> problem doesn't happen.
> 
> [adding Jan to CC:]
> 
> I'm just curious about this bug's origin. For me, it's GTK3-only issue,
> and everything works fine with GTK2; but the original report from Xue
> notes GTK2.
> 
> I found that the size values returned by gtk_widget_get_preferred_size
> in xg_update_tool_bar_sizes are different for GTK3 and GTK2. For GTK2,
> width and height are always 47 and 44 pixels; for GTK3, it's 37x36 for
> the first call to xg_update_tool_bar_size and 43x44 for the subsequent
> calls. Visually the toolbar size doesn't change and it looks the same
> between GTK2 and GTK3.
> 
> Finally, this seems to be a question for Jan: GTK3 docs says that the
> handle box widget is obsolete (http://developer.gnome.org/gtk3/stable/GtkHandleBox.html),
> so why we prefer it for both GTK2 and GTK3?
> 
> Dmitry

bug#13512: 24.3.50; Mini-window glitch with GTK

[Dmitry Antipov]

On 02/14/2013 11:02 PM, Jan Djärv wrote:

> This has been fixed in the trunk.

Verified with r111785 and looks good, thanks.

Dmitry