emacs-devel
[Top][All Lists]
Advanced

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

Re: Shrinking frames as of past month


From: Jan Djärv
Subject: Re: Shrinking frames as of past month
Date: Fri, 28 Mar 2008 11:35:41 +0100
User-agent: Thunderbird 2.0.0.12 (X11/20080213)



Andrew W. Nosenko skrev:
On Sun, Mar 23, 2008 at 11:38 PM, Michael Olson <address@hidden> wrote:
Jan Djärv <address@hidden> writes:


It seems it is a bug in Gtk+,
 > http://bugzilla.gnome.org/show_bug.cgi?id=68668
 > (http://bugzilla.gnome.org/show_bug.cgi?id=137822 explains it a bit
 > better).
 >
 > Basically because the menu bar is too large for the frame, Gtk+ sets a
 > base width that isn't a multiple of the width increment.  This makes
 > the window manager shrink the text area (by 2 pixels in my case) so
 > that framw width - base width is a multiple of the width increment.
 > Then when leaving dired, we get a correct base width again.  But the 2
 > pixels aren't put back, rather the window manager shrinks even more to
 > get the frame to be a multiple of the width increment.

 That sounds plausible.  I updated the rest of my system today, and the
 problem went away, so it seems to have been the fault of GTK.


Could you say, which version of GTK you updated to?
Reason: I have lates stable (gtk-2.12.9) but problem didn't gone.


I don't think the problem is fixed, the bugzilla entry is still open.
You don't see the problem if your frame is wide enough to make room for direds menu bar, or if you don't have the menu bar visible. I suspect that is what happens.

It might also be pure luck. I.e. the font used by the menu bar is such that the base width happens to be a multiple of the width increment. Or perhaps a newer Gtk+ calculates the base width slightly differently.

        Jan D.




reply via email to

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