[Top][All Lists]

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

[debbugs-tracker] bug#13512: closed (24.3.50; Mini-window glitch with GT

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#13512: closed (24.3.50; Mini-window glitch with GTK)
Date: Thu, 14 Feb 2013 19:04:02 +0000

Your message dated Thu, 14 Feb 2013 20:02:25 +0100
with message-id <address@hidden>
and subject line Re: bug#13512: 24.3.50; Mini-window glitch with GTK
has caused the debbugs.gnu.org bug report #13512,
regarding 24.3.50; Mini-window glitch with GTK
to be marked as done.

(If you believe you have received this mail in error, please contact

13512: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13512
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 24.3.50; Mini-window glitch with GTK Date: Mon, 21 Jan 2013 20:26:01 +0800
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 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.13)
 of 2013-01-20 on Emacs
Bzr revision: 111567 address@hidden
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.

(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.

--- End Message ---
--- Begin Message --- Subject: Re: bug#13512: 24.3.50; Mini-window glitch with GTK Date: Thu, 14 Feb 2013 20:02:25 +0100

This has been fixed in the trunk.

        Jan D.

22 jan 2013 kl. 15:55 skrev Dmitry Antipov <address@hidden>:

> 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

--- End Message ---

reply via email to

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