[Top][All Lists]

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

[Emacs-bug-tracker] bug#8919: closed (24.0.50; Ever-changing frame size

From: GNU bug Tracking System
Subject: [Emacs-bug-tracker] bug#8919: closed (24.0.50; Ever-changing frame size for GTK3 toolkit on a KDE4 desktop)
Date: Sun, 26 Jun 2011 18:52:02 +0000

Your message dated Sun, 26 Jun 2011 20:51:13 +0200
with message-id <address@hidden>
and subject line Re: bug#8919: 24.0.50; Ever-changing frame size for GTK3 
toolkit on a KDE4 desktop
has caused the GNU bug report #8919,
regarding 24.0.50; Ever-changing frame size for GTK3 toolkit on a KDE4 desktop
to be marked as done.

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

8919: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8919
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 24.0.50; Ever-changing frame size for GTK3 toolkit on a KDE4 desktop Date: Wed, 22 Jun 2011 13:04:10 +0200
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Please check that the From: line gives an address where you can be reached.
Your report will be posted to the address@hidden mailing list
and the gnu.emacs.bug news group, and at http://debbugs.gnu.org.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

1. Compile Emacs from Bzr repository with the GTK3 toolkit.
2. Start Emacs on a KDE4 desktop.
3. Starting to use Emacs dimish its frame size, and the frame size is
changing with nearly every command.

Remark: Using the GTK2 toolkit avoids this bug. Maybe it is caused by
the following change reported in `src/ChangeLog':
2011-06-14  Jan Djärv  <address@hidden>

        * xfns.c (x_set_scroll_bar_default_width): Remove argument to

        * gtkutil.c: Include emacsgtkfixed.h if HAVE_GTK3.
        (int_gtk_range_get_value): Move to the scroll bar part of the file.
        (style_changed_cb): Call update_theme_scrollbar_width and call
        x_set_scroll_bar_default_width and xg_frame_set_char_size for
        all frames (Bug#8505).
        (xg_create_frame_widgets): Call emacs_fixed_new if HAVE_GTK3 (Bug#8505).
        Call gtk_window_set_resizable if HAVE_GTK3.
        (x_wm_set_size_hint): Call emacs_fixed_set_min_size with min width
        and height if HAVE_GTK3 (Bug#8505).
        (scroll_bar_width_for_theme): New variable.
        (update_theme_scrollbar_width): New function.
        (xg_get_default_scrollbar_width): Move code to
        update_theme_scrollbar_width, just return scroll_bar_width_for_theme.
        (xg_initialize): Call update_theme_scrollbar_width.

        * gtkutil.h (xg_get_default_scrollbar_width): Remove argument.

        * emacsgtkfixed.c, emacsgtkfixed.h: New files.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file

In GNU Emacs (x86_64-unknown-linux-gnu, GTK+ Version 3.0.11)
 of 2011-06-22 on red
Windowing system distributor `The X.Org Foundation', version 11.0.11002000
configured using `configure  '--prefix=/usr' '--sysconfdir=/etc'
'--localstatedir=/var' '--libexecdir=/usr/lib'
'--mandir=/usr/share/man' '--without-sound' '--with-x-toolkit=gtk3'
'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe'
'LDFLAGS=-Wl,--hash-style=gnu -Wl,--as-needed''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: nil
  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:
M-x r e p o r t <tab> <return>

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

Load-path shadows:
/usr/share/emacs/site-lisp/coq-db hides
/usr/share/emacs/site-lisp/coq-syntax hides
/usr/share/emacs/site-lisp/coq hides

(shadow sort gnus-util time-date mail-extr message idna sendmail
regexp-opt format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mailabbrev mail-utils gmm-utils mailheader emacsbug tooltip
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image fringe 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 files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)

--- End Message ---
--- Begin Message --- Subject: Re: bug#8919: 24.0.50; Ever-changing frame size for GTK3 toolkit on a KDE4 desktop Date: Sun, 26 Jun 2011 20:51:13 +0200 User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv: Gecko/20110613 Thunderbird/3.1.11

I've checked in a really ugly solution (overriding X11 functions). This only applies to Gtk3. Maybe we should do like Firefox and only use Gtk for the style specific drawing, thus bypassing all the strange behaviour. No time for that before feature freeze, though.

        Jan D.

Jan Djärv skrev 2011-06-26 17.36:

Jan Djärv skrev 2011-06-24 12.58:

Dirk Ullrich skrev 2011-06-24 11.47:

I must confess that this the first time that I suffer from this
shrinking of Emacs on KDE. (I use the Emacs' development version built
for the GTK2 toolkit right from the beginning.) Maybe that the bug
occured for an Emacs revision I didn't build. And for GTK2 it even
doesn't happen at all yet - at least for me.

By the way - for curiousity I reverted to revision 104583 i.e. the
last one for your last GTK3-related changes. For this revision the
shrinking error does not occur.


This is not surprising, it is a timing issue.

Actually its not a timing issue. KDE uses min_width/height to calculate
geometry constraints, i.e. a window shall obey

width = ((width - min_width)/width_inc) * width_inc + min_width

Ditto for height. This is OK if min_width is a multiple of width_inc.

That may be seen as a bug in it self as base_size is what should be used, and
that is what Gtk3 (and 2) uses.

But Gtk3 sets min size by itself now, ignoring any min size set by Emacs (a
gigantic bug IMHO). But Gtk3 doesn't bother to adjust min width so it is a
multiple of width_inc (ditto for height). This is another bug.

And in the style that Gtk+/Gnome is developed in ("we know best"), Gtk+
actually resizes the frame after the window manager has resized it (bug #3).
That is so Gtk+ can force its "we know best" view of what the size the frame
shall have according to Gtk+, never mind that Emacs, the window manager and
the user has another view.

So in my case we set width to 680 pixel. But KDE calculates with the formula
above that the width should be 378 pixels so it, being the window manager,
resizes the frame to that. Gtk3 then sees that the frame has been resized, and
rather than just accepting the size like any well behaved toolkit should do,
it resizes again, now to 672 (width_inc is 8 here). And KDE then resizes to
370. And Gtk+ to 664. And KDE to 662. And so on. With luck they find a common
denominator, or otherwise the frame gets resized until it hits the min width.

If you move/hide the scroll bar, or menu bar or tool bar, Gtk+ sets a new min
width/height, and the dance is on again.

This is so ugly, so maybe Emacs should remove Gtk3 support for this release?

There doesn't seem to be any sane way around this, except rewriting Gtk3+
widgets to not set any min size other that the one the application has set.

Jan D.

--- End Message ---

reply via email to

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