[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8919: 24.0.50; Ever-changing frame size for GTK3 toolkit on a KDE4 d
bug#8919: 24.0.50; Ever-changing frame size for GTK3 toolkit on a KDE4 desktop
Sun, 26 Jun 2011 20:51:13 +0200
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:126.96.36.199) 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 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.