Shrinking frames as of past month

Shrinking frames as of past month

[Michael Olson]

<#part sign=pgpmime>
When I replaced my Emacs binary that was compiled in February with one
compiled from today's CVS HEAD, I noticed some very aberrant behavior
WRT frames.  I haven't updated the rest of my system in that time, such
as libraries, so it must be due to a change in Emacs.  It happens with
"emacs -Q" as well, so it's not caused to my init file.

Basically, GTK frames seem to shrink by about one character length every
time I do certain things such hitting viewing mail on Gnus, hitting the
key combination "M-x", or displaying an image by hitting RET on it in
dired.

The easiest way to replicate this is to view a directory which contains
image files in dired, and hit RET on one of them.  The frame will
shrink.  Hit C-x b to switch back and forth between the image and the
directory, and the frame will shrink further.  It might be necessary to
initially have the frame small enough that a line-wrap indicator shows
up in the fringe.

I also notice then when I resize the frames back to take up the original
amount of pixels in width, that the window manager thinks the dimensions
of the window are different than they are.  In two frames with the same
number of pixels long, and with Emacs displaying the same number of
characters, one is thought to be 80x35 by the window manager and the
other one (the one that shrank earlier) is thought to be 70x35.

Here are my compilation options:

Configured for `i686-pc-linux-gnu'.

  Where should the build process find the source code?    /stuff/proj/emacs/emacs/git-emacs
  What operating system and machine description files should Emacs use?
        `s/gnu-linux.h' and `m/intel386.h'
  What compiler should emacs be built with?               gcc -g -O2 -Wno-pointer-sign 
  Should Emacs use the GNU version of malloc?             yes
      (Using Doug Lea's new malloc from the GNU C Library.)
  Should Emacs use a relocating allocator for buffers?    yes
  Should Emacs use mmap(2) for buffer allocation?         no
  What window system should Emacs use?                    x11
  What toolkit should Emacs use?                          GTK
  Where do we find X Windows header files?                Standard dirs
  Where do we find X Windows libraries?                   Standard dirs
  Does Emacs use -lXaw3d?                                 no
  Does Emacs use -lXpm?                                   yes
  Does Emacs use -ljpeg?                                  yes
  Does Emacs use -ltiff?                                  yes
  Does Emacs use a gif library?                           yes -lgif
  Does Emacs use -lpng?                                   yes
  Does Emacs use -lrsvg-2?                                yes
  Does Emacs use -lgpm?                                   no
  Does Emacs use -ldbus?                                  yes
  Does Emacs use a font backend?                          yes
  Does Emacs use -lfreetype?                              yes
  Does Emacs use -lm17n-flt?                              no
  Does Emacs use -lotf?                                   no
  Does Emacs use -lxft?                                   yes
  Does Emacs use X toolkit scroll bars?                   yes

  Compiling with sync input.

Using --disable-sync-input did not make any difference.

-- 
|       Michael Olson  |  FSF Associate Member #652     |
| http://mwolson.org/  |  Hobbies: Lisp, HCoop          |
| Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
`-------------------------------------------------------'

Re: Shrinking frames as of past month

[Jan Djärv]

Michael Olson skrev:
> <#part sign=pgpmime>
> When I replaced my Emacs binary that was compiled in February with one
> compiled from today's CVS HEAD, I noticed some very aberrant behavior
> WRT frames.  I haven't updated the rest of my system in that time, such
> as libraries, so it must be due to a change in Emacs.  It happens with
> "emacs -Q" as well, so it's not caused to my init file.
> 
> Basically, GTK frames seem to shrink by about one character length every
> time I do certain things such hitting viewing mail on Gnus, hitting the
> key combination "M-x", or displaying an image by hitting RET on it in
> dired.

Does this always involves an image, or does it happen when you view ordinary 
text mail in Gnus also?

> 
> The easiest way to replicate this is to view a directory which contains
> image files in dired, and hit RET on one of them.  The frame will
> shrink.  Hit C-x b to switch back and forth between the image and the
> directory, and the frame will shrink further.  It might be necessary to
> initially have the frame small enough that a line-wrap indicator shows
> up in the fringe.

Cool, we have shrinkage in both dimensions now :-).


> 
> I also notice then when I resize the frames back to take up the original
> amount of pixels in width, that the window manager thinks the dimensions
> of the window are different than they are.  In two frames with the same
> number of pixels long, and with Emacs displaying the same number of
> characters, one is thought to be 80x35 by the window manager and the
> other one (the one that shrank earlier) is thought to be 70x35.
> 

That is wm size hints that aren't updated properly.  The bug is why the frame 
shrinks when viewing an image. I can reproduce it, so a fix should be done 
within a couple of days or so.

	Jan D.

Re: Shrinking frames as of past month

[Michael Olson]

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Michael Olson skrev:
>> When I replaced my Emacs binary that was compiled in February with
>> one compiled from today's CVS HEAD, I noticed some very aberrant
>> behavior WRT frames.  I haven't updated the rest of my system in that
>> time, such as libraries, so it must be due to a change in Emacs.  It
>> happens with "emacs -Q" as well, so it's not caused to my init file.
>>
>> Basically, GTK frames seem to shrink by about one character length
>> every time I do certain things such hitting viewing mail on Gnus,
>> hitting the key combination "M-x", or displaying an image by hitting
>> RET on it in dired.
>
> Does this always involves an image, or does it happen when you view
> ordinary text mail in Gnus also?

It happens when viewing ordinary text as well, particularly if there are
2 windows on the frame.

-- 
|       Michael Olson  |  FSF Associate Member #652     |
| http://mwolson.org/  |  Hobbies: Lisp, HCoop          |
| Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
`-------------------------------------------------------'

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Shrinking frames as of past month

[Sam Steingold]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Djärv wrote:
|
|
| Michael Olson skrev:
|> <#part sign=pgpmime>
|> When I replaced my Emacs binary that was compiled in February with one
|> compiled from today's CVS HEAD, I noticed some very aberrant behavior
|> WRT frames.  I haven't updated the rest of my system in that time, such
|> as libraries, so it must be due to a change in Emacs.  It happens with
|> "emacs -Q" as well, so it's not caused to my init file.
|>
|> Basically, GTK frames seem to shrink by about one character length every
|> time I do certain things such hitting viewing mail on Gnus, hitting the
|> key combination "M-x", or displaying an image by hitting RET on it in
|> dired.
|
| Does this always involves an image, or does it happen when you view
| ordinary text mail in Gnus also?

I get it on entering dired (no images involved)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH4Tn4Pp1Qsf2qnMcRAmdgAKCXobXbjP6pdGxDqkkjAhzzMNSDtACaAvFI
qRQt8rGi6wpQ+jwYvjeVhW0=
=RAnF
-----END PGP SIGNATURE-----

Re: Shrinking frames as of past month

[Francesc Rocher]

Sam Steingold wrote:

>|> Basically, GTK frames seem to shrink by about one character length every
>|> time I do certain things such hitting viewing mail on Gnus, hitting the
>|> key combination "M-x", or displaying an image by hitting RET on it in
>|> dired.
>|
>| Does this always involves an image, or does it happen when you view
>| ordinary text mail in Gnus also?
>
>
>I get it on entering dired (no images involved)

Yes, me too, but only on the initial frame. This effect disapears on
subsequent frames.


-- 
Francesc Rocher

Re: Shrinking frames as of past month

[Jan Djärv]

Francesc Rocher skrev:
> Sam Steingold wrote:
> 
>> |> Basically, GTK frames seem to shrink by about one character length every
>> |> time I do certain things such hitting viewing mail on Gnus, hitting the
>> |> key combination "M-x", or displaying an image by hitting RET on it in
>> |> dired.
>> |
>> | Does this always involves an image, or does it happen when you view
>> | ordinary text mail in Gnus also?
>>
>>
>> I get it on entering dired (no images involved)
> 
> Yes, me too, but only on the initial frame. This effect disapears on
> subsequent frames.
> 

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.

So for me I get (my width inc is 6 pixels)

enter dired => shrink 2 pixels,
leave dired => shrink 4 pixels,
enter dired => shrink 2 pixels,
...
and so on.

There is talk about a workaround in the gnome-terminal sources, I'll check it out.

If the menu bar is disabled, or the size of the frame is large enough to show
the whole dired menubar, shrinking does not occur.

	Jan D.

Re: Shrinking frames as of past month

[Michael Olson]

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

Jan Djärv <jan.h.d@swipnet.se> 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.

-- 
|       Michael Olson  |  FSF Associate Member #652     |
| http://mwolson.org/  |  Hobbies: Lisp, HCoop          |
| Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
`-------------------------------------------------------'

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Shrinking frames as of past month

[Andrew W. Nosenko]

On Sun, Mar 23, 2008 at 11:38 PM, Michael Olson <mwolson@gnu.org> wrote:
> Jan Djärv <jan.h.d@swipnet.se> 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.

-- 
Andrew W. Nosenko <andrew.w.nosenko@gmail.com>

Re: Shrinking frames as of past month

[Jan Djärv]

Andrew W. Nosenko skrev:
> On Sun, Mar 23, 2008 at 11:38 PM, Michael Olson <mwolson@gnu.org> wrote:
>> Jan Djärv <jan.h.d@swipnet.se> 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.

Re: Shrinking frames as of past month

[Jan Djärv]

This should be fixed now.  Please test.

	Jan D.

Francesc Rocher skrev:
> Sam Steingold wrote:
> 
>> |> Basically, GTK frames seem to shrink by about one character length every
>> |> time I do certain things such hitting viewing mail on Gnus, hitting the
>> |> key combination "M-x", or displaying an image by hitting RET on it in
>> |> dired.
>> |
>> | Does this always involves an image, or does it happen when you view
>> | ordinary text mail in Gnus also?
>>
>>
>> I get it on entering dired (no images involved)
> 
> Yes, me too, but only on the initial frame. This effect disapears on
> subsequent frames.
> 
> 

Re: Shrinking frames as of past month

[Francesc Rocher]

On Sun, Mar 30, 2008 at 7:39 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> This should be fixed now.  Please test.
>
>         Jan D.

Ok, it's fixed.

-- 
Francesc Rocher

Re: Shrinking frames as of past month

[Jan Djärv]

Francesc Rocher skrev:
> On Sun, Mar 30, 2008 at 7:39 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> This should be fixed now.  Please test.
>>
>>         Jan D.
> 
> Ok, it's fixed.
> 

Thanks for testing.

	Jan D.