all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#13512: 24.3.50; Mini-window glitch with GTK
@ 2013-01-21 12:26 Xue Fuqiao
  2013-01-22  8:01 ` Eli Zaretskii
  0 siblings, 1 reply; 8+ messages in thread
From: Xue Fuqiao @ 2013-01-21 12:26 UTC (permalink / raw)
  To: 13512


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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#13512: 24.3.50; Mini-window glitch with GTK
  2013-01-21 12:26 bug#13512: 24.3.50; Mini-window glitch with GTK Xue Fuqiao
@ 2013-01-22  8:01 ` Eli Zaretskii
  2013-01-22  9:44   ` Dmitry Antipov
  0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2013-01-22  8:01 UTC (permalink / raw)
  To: Xue Fuqiao, Dmitry Antipov; +Cc: 13512

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#13512: 24.3.50; Mini-window glitch with GTK
  2013-01-22  8:01 ` Eli Zaretskii
@ 2013-01-22  9:44   ` Dmitry Antipov
  2013-01-22 11:41     ` Eli Zaretskii
  0 siblings, 1 reply; 8+ messages in thread
From: Dmitry Antipov @ 2013-01-22  9:44 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Xue Fuqiao, 13512

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







^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#13512: 24.3.50; Mini-window glitch with GTK
  2013-01-22  9:44   ` Dmitry Antipov
@ 2013-01-22 11:41     ` Eli Zaretskii
  2013-01-22 14:55       ` Dmitry Antipov
  0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2013-01-22 11:41 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: xfq.free, 13512

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#13512: 24.3.50; Mini-window glitch with GTK
  2013-01-22 11:41     ` Eli Zaretskii
@ 2013-01-22 14:55       ` Dmitry Antipov
  2013-01-24  6:37         ` Jan Djärv
  2013-02-14 19:02         ` Jan Djärv
  0 siblings, 2 replies; 8+ messages in thread
From: Dmitry Antipov @ 2013-01-22 14:55 UTC (permalink / raw)
  To: 13512; +Cc: xfq.free

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






^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#13512: 24.3.50; Mini-window glitch with GTK
  2013-01-22 14:55       ` Dmitry Antipov
@ 2013-01-24  6:37         ` Jan Djärv
  2013-02-14 19:02         ` Jan Djärv
  1 sibling, 0 replies; 8+ messages in thread
From: Jan Djärv @ 2013-01-24  6:37 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: xfq.free, 13512

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.







^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#13512: 24.3.50; Mini-window glitch with GTK
  2013-01-22 14:55       ` Dmitry Antipov
  2013-01-24  6:37         ` Jan Djärv
@ 2013-02-14 19:02         ` Jan Djärv
  2013-02-15  5:30           ` Dmitry Antipov
  1 sibling, 1 reply; 8+ messages in thread
From: Jan Djärv @ 2013-02-14 19:02 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: xfq.free, 13512-done

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






^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#13512: 24.3.50; Mini-window glitch with GTK
  2013-02-14 19:02         ` Jan Djärv
@ 2013-02-15  5:30           ` Dmitry Antipov
  0 siblings, 0 replies; 8+ messages in thread
From: Dmitry Antipov @ 2013-02-15  5:30 UTC (permalink / raw)
  To: Jan Djärv; +Cc: xfq.free, 13512-done

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







^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2013-02-15  5:30 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-21 12:26 bug#13512: 24.3.50; Mini-window glitch with GTK Xue Fuqiao
2013-01-22  8:01 ` Eli Zaretskii
2013-01-22  9:44   ` Dmitry Antipov
2013-01-22 11:41     ` Eli Zaretskii
2013-01-22 14:55       ` Dmitry Antipov
2013-01-24  6:37         ` Jan Djärv
2013-02-14 19:02         ` Jan Djärv
2013-02-15  5:30           ` Dmitry Antipov

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.