Re: base size and resize increment window manager attributes

[Neil Zanella <nzanella cs mun ca>]

On Wed, 26 Jun 2002, Matthias Clasen wrote:

> > Here is one simple thing
> > which should probably be part of the standard:
> > 
> > +++ Each window must have an interior with a height of at least 1 pixel
> > +++ and a width of at least one pixel.
> 
> This is already enforced by the X protocol.

Could you quote the source or document where this rule is specified?

> > Another requirement should be:
> > 
> > +++ The size increment should be always greater than 1.
> > +++ Setting the size increment to a smaller amount is implementation
> > +++ defined, i.e., should be avoided.
> 
> Well, its all only hints anyway, the clients should still try to work with
> the window size the wm gave them. But in this particular case, I don't
> see any problem with a size increment of 0. The ICCCM says:
> 
> The base_width and base_height elements in conjunction with width_inc and
> height_inc define an arithmetic progression of preferred window widths and
> heights for nonnegative integers i and j:
>
> width = base_width + (i × width_inc)
> height = base_height + (j × height_inc)

This means that if the base_width and base_height are equal to zero then 
the window is not resizable. In this case the manual should specify what
happens when a window starts up with a size that is is not equal to
(base_width, base_height). For instance there should be a rule that
specifies:

+++ When width_inc is set to zero then the window shall be resized to have
+++ a width of base_width. When the height_inc is set to zero than the
+++ window should be set to have an initial size of base_height.

As a matter of fact there should be a rule stating whether or not windows 
should be resized upon startup so that their size satisfies the above
equations, and if so, then how the window should be resized (e.g.
by rounding down).

> > +++ The size of a window SHOLD be computed as follows:
> > 
> > Let k be some scalar factor.
> > 
> > s = baseSize + k * sizeIncrement;
> > if (s == 0) size = 1;
> > else size = baseSize + k * sizeIncrement;
> > 
> 
> Don't forget the min and max size hints. I think it is pretty clear from 
> ICCCM 4.1.2.3 that a baseSize smaller than minSize is allowed.

To be precise, there should be a rule stating the following:

+++ baseSize should be less than or equal to minSize but greater than or 
+++ equal to 1 in each coordinate, since as you stated, the X protocol
+++ enforces the interor of a window is at least 1x1

> > Under the gnome, since the base size is (0, 0), gnome automatically
> > bumps it to (1, 1) which means that the size computations above
> > yield sizes of (1, 1), (3, 3), (5, 5), ...
> > which is not what the user expected.
> 
> You have to be more specific here. "gnome" is not a window manager.
> The behaviour you describe would be a bug of the wm you're running
> gnome with.

To be specific I am talking about /usr/bin/gnome-session as shipped
from package gnome-core-1.4.0.4-54 from the Red Hat 7.3 distribution.
Could you confirm this for me. The code I posted can be compiled
under Qt 3 with qmake -project; qmake; make

I really don't see why the WM would bump up base_width to 1.

> > These things need to be sorted out and standardized because
> > it can really mess things up for larger applications and we
> > all need something to rely on.
> 
> I think the ICCCM is completely precise in this area. If anything, section
> 4.1.2.3
> could contain a hint to watch out for division by zero when checking the
> aspect ratio, since requested size - baseSize might be zero.

+++ There should be a rule stating that base_width and width_inc cannot be
+++ simultaneously zero since this would imply a constant preferred with 
+++ of zero which is impossible as you have stated.

+++ There should also be a section stating whether upon startup the window
+++ should be resized to a preferred size or not. I think it should be.

Regards,

Neil