GNOME Bugzilla – Bug 133145
Maximising gvim obscures part of its status line
Last modified: 2007-11-18 21:11:05 UTC
When I maximise gvim (GTK+ 2 version) it seems to think there's more vertical space than there really is, so it sometimes tries to display one more row than it can actually fit all of, depending on font, screen size etc. This results in half of its status line being obscured either off the bottom of the screen or by the Gnome panel. I noticed this because the settings I started using recently:- Metacity Simple theme, Gnome icon Bluecurve theme, Gnome panel height 36, screen size 1024x768, gvim font LucidaTypewriter 11 - caused the right set of circumstances. Merely changing the icon theme to Simple cures it, but changing the font size/family in gvim can make it resurface. I reported it on vim-dev first, but Bram Moolenaar thinks it's a wm bug.
screenshot?
Created attachment 23951 [details] Screenshot of problem
If the left edge of the screenshot looks odd, ignore it, I use Xinerama and trimmed off the extra screen with Gimp, so I might have been out by the odd pixel. I got some terminology wrong in my first report too, I meant controls theme where I put icon theme.
Hmmm. Kinda looks like it's exactly one line too long. The funny thing is that metacity doesn't try to enforce size increment constraints in maximized windows any more. What version of metacity are you using there (metacity --version)? Can you get this to happen with other windows (xterm, gnome-terminal, emacs, etc)?
I'm using metacity 2.6.3. I haven't been able to reproduce the bug with gnome-terminal, sawfish or kwm, but I could try harder! I had another thought, perhaps it's something to do with the bottom edge of the window frame disappearing when maximised. I've only ever seen metacity do that as well. It could still be a gvim bug, but one that's unique to metacity.
no I'm pretty sure it's a metacity bug.
Yes, it is a metacity bug. As Rob said, "metacity doesn't try to enforce size increment constraints in maximized windows any more" which I believe is a nasty bug. (I have gnome 2.8.2 with metacity 2.8.8.) This bug causes other applications, e.g. vte (gnome-terminal) and xchat to misbehave, see it described in details here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=104768
I think originally when I looked at that screenshot I had thought that metacity was sizing the window so that it went behind the panel. But looking at it again, I think that actually the window has the correct size and that it's gvim that's misbehaving. The specifications on size increment hints are quite clear that the application must not _depend_ on the window manager enforcing them all the time.
I haven't read any specifications but I trust you and believe that these size hints are hints only and not requirements. However, we do have at least three applications by now that are known to misbehave in this situation. So even if they are all buggy and even if we're trying to get their maintainers fix them, it would be nice if metacity worked around this issue by choosing a size that honours the hint. So even if it's not a metacity bug, please at least consider it as a metacity feature request :)
Everyone and their extended family reported the other behavior (enforce the grid hint for maximized windows) as a bug, and I don't think toggling our behavior every release depending on who complains makes sense. These apps will just have to be fixed to do something sensible when given extra space. We are doing the same thing as KWin iirc so this is the standard desktop behavior, and it's allowed by the specs.
*** Bug 497094 has been marked as a duplicate of this bug. ***