Subject: Re: bug#8919: 24.0.50; Ever-changing frame size for GTK3 toolkit on a KDE4 desktop

From: Jan Djärv <[email-masked]>
Date: Sun, 26 Jun 2011 20:51:13 +0200

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.