GNOME Bugzilla – Bug 542373
metacity does not respect window size restrictions
Last modified: 2008-07-13 01:49:07 UTC
Please describe the problem: Some windows have restrictions on which size they can have. For example, gnome-terminal always resizes in multiples of the size of a single glyph, so that the number of characters in rows and columns is always integer. During a normal window resize this restriction is somehow imposed. However, if you use any of the maximize functions (horizontal maximization, vertical maximization, full maximization), the respective window size gets a invalid (from application point of view) value. In the best case (e.g. gnome-terminal) you will get black background in those areas which can't hold a whole character. But some other applications (for example the xfte editor) don't even bother to paint in those areas since from application point of view this is a impossible situation. Thus, with xfte you will see garbage in non-character-size-multiple areas. Steps to reproduce: 1. Run gnome-terminal 2. Use any of three maximization functions enumerated above 3. You will get an non-integer number of characters along some dimension. If you're lucky enough it could happen that you get an ideal fit, in which case change terminal font size and goto 2. Actual results: Expected results: Does this happen every time? Other information:
Metacity does respect size restrictions, as you pointed out. It's just that when it has *conflicting* size restrictions (possibilities: maximized == screen size vs. size increments, min size vs. max size (illogical app authors exist), max size vs. fullscreened, base size & increment size vs min & max sizes, aspect ratio vs size increment, aspect ratio vs. maximized, uposition/pposition vs. on-single-xinerama, uposition/pposition vs. size-increment/size-limit etc., focus-under-mouse vs. focus-under-last-focused-window on workspace switch, keynav vs. mousenav at the moment of switch, focus-under-mouse vs. grabs, focus-under-mouse vs. new windows getting focus), then it has to make a judgement call about which contraints are more important than the others. There's a few other bugs in here, but basically either choice was going to cause lots of issues, and really the only one providing a sane choice for the end user was to follow their maximization request (how are they supposed to know about size increments?) Most apps have long since been fixed to handle a little bit of extra space. Sounds like xfte needs to be fixed too--please file a bug report against that program.
That didn't come out very clearly. I listed some conflicting restrictions that weren't size restrictions...guess I got carried away and just listed a few other inherently conflicting choices the window manager has to deal with. Also, by "there's a few other bugs in here" I meant "there's a few other bug reports on this exact same issue where this has already been discussed." We should probably track down those numbers and stick them in rationales.txt, but I was too lazy to look up the numbers and mark this as a duplicate of those other bugs. *shrug*
To add one other pedantic note, the specs are quite clear that the size hints are hints, not restrictions. By the letter of the spec it's perfectly fine for the WM to ignore these hints entirely. Apps that break if the hints aren't used as they expect are not consistent with the spec. That said if the spec were wrong, we could just change it, but in this case the spec matches what should happen (maximize should override the size increment hints).