unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#8919: 24.0.50; Ever-changing frame size for GTK3 toolkit on a KDE4 desktop
@ 2011-06-22 11:04 Dirk Ullrich
  2011-06-23 17:48 ` Jan Djärv
  0 siblings, 1 reply; 6+ messages in thread
From: Dirk Ullrich @ 2011-06-22 11:04 UTC (permalink / raw)
  To: 8919

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 bug-gnu-emacs@gnu.org 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  <jan.h.d@swipnet.se>

	* xfns.c (x_set_scroll_bar_default_width): Remove argument to
	xg_get_default_scrollbar_width.

	* 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
/usr/share/emacs/24.0.50/etc/DEBUG.


In GNU Emacs 24.0.50.1 (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/ProofGeneral/coq/coq-db
/usr/share/emacs/site-lisp/coq-syntax hides
/usr/share/emacs/site-lisp/ProofGeneral/coq/coq-syntax
/usr/share/emacs/site-lisp/coq hides
/usr/share/emacs/site-lisp/ProofGeneral/coq/coq

Features:
(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)





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

* bug#8919: 24.0.50; Ever-changing frame size for GTK3 toolkit on a KDE4 desktop
  2011-06-22 11:04 bug#8919: 24.0.50; Ever-changing frame size for GTK3 toolkit on a KDE4 desktop Dirk Ullrich
@ 2011-06-23 17:48 ` Jan Djärv
  2011-06-24  9:47   ` Dirk Ullrich
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Djärv @ 2011-06-23 17:48 UTC (permalink / raw)
  To: Dirk Ullrich; +Cc: 8919

Hi.

We have had shrinking on KDE before GTK3.  It comes and goes.
GTK3 now sets wm size hits behind our backs, it is probably that that triggers it.

	Jan D.


Dirk Ullrich skrev 2011-06-22 13.04:
> 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 bug-gnu-emacs@gnu.org 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<jan.h.d@swipnet.se>
>
> 	* xfns.c (x_set_scroll_bar_default_width): Remove argument to
> 	xg_get_default_scrollbar_width.
>
> 	* 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
> /usr/share/emacs/24.0.50/etc/DEBUG.
>
>
> In GNU Emacs 24.0.50.1 (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/ProofGeneral/coq/coq-db
> /usr/share/emacs/site-lisp/coq-syntax hides
> /usr/share/emacs/site-lisp/ProofGeneral/coq/coq-syntax
> /usr/share/emacs/site-lisp/coq hides
> /usr/share/emacs/site-lisp/ProofGeneral/coq/coq
>
> Features:
> (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)
>
>





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

* bug#8919: 24.0.50; Ever-changing frame size for GTK3 toolkit on a KDE4 desktop
  2011-06-23 17:48 ` Jan Djärv
@ 2011-06-24  9:47   ` Dirk Ullrich
  2011-06-24 10:58     ` Jan Djärv
  0 siblings, 1 reply; 6+ messages in thread
From: Dirk Ullrich @ 2011-06-24  9:47 UTC (permalink / raw)
  To: 8919

Hi Jan,

2011/6/23 Jan Djärv <jan.h.d@swipnet.se>:
> Hi.
>
> We have had shrinking on KDE before GTK3.  It comes and goes.
> GTK3 now sets wm size hits behind our backs, it is probably that that
> triggers it.
>
>        Jan D.
[...]
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.

Dirk





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

* bug#8919: 24.0.50; Ever-changing frame size for GTK3 toolkit on a KDE4 desktop
  2011-06-24  9:47   ` Dirk Ullrich
@ 2011-06-24 10:58     ` Jan Djärv
  2011-06-26 15:36       ` Jan Djärv
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Djärv @ 2011-06-24 10:58 UTC (permalink / raw)
  To: Dirk Ullrich; +Cc: 8919



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.

Hi.

This is not surprising, it is a timing issue.

	Jan D.





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

* bug#8919: 24.0.50; Ever-changing frame size for GTK3 toolkit on a KDE4 desktop
  2011-06-24 10:58     ` Jan Djärv
@ 2011-06-26 15:36       ` Jan Djärv
  2011-06-26 18:51         ` Jan Djärv
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Djärv @ 2011-06-26 15:36 UTC (permalink / raw)
  To: Dirk Ullrich; +Cc: 8919



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





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

* bug#8919: 24.0.50; Ever-changing frame size for GTK3 toolkit on a KDE4 desktop
  2011-06-26 15:36       ` Jan Djärv
@ 2011-06-26 18:51         ` Jan Djärv
  0 siblings, 0 replies; 6+ messages in thread
From: Jan Djärv @ 2011-06-26 18:51 UTC (permalink / raw)
  To: Dirk Ullrich; +Cc: 8919-done

Hello.

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





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

end of thread, other threads:[~2011-06-26 18:51 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-22 11:04 bug#8919: 24.0.50; Ever-changing frame size for GTK3 toolkit on a KDE4 desktop Dirk Ullrich
2011-06-23 17:48 ` Jan Djärv
2011-06-24  9:47   ` Dirk Ullrich
2011-06-24 10:58     ` Jan Djärv
2011-06-26 15:36       ` Jan Djärv
2011-06-26 18:51         ` Jan Djärv

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).