GNU bug report logs - #8919
24.0.50; Ever-changing frame size for GTK3 toolkit on a KDE4 desktop

Previous Next

Full log

Message #17 received at 8919 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Dirk Ullrich <dirk.ullrich <at> googlemail.com>
Cc: 8919 <at> debbugs.gnu.org
Subject: Re: bug#8919: 24.0.50; Ever-changing frame size for GTK3 toolkit
	on a KDE4 desktop
Date: Sun, 26 Jun 2011 17:36:16 +0200

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.