Re: icewm: patch about aspect ratio

[Owen Taylor <otaylor redhat com>]

Marko Macek <Marko.Macek@gmx.net> writes:

> Chi-Deok Hwang wrote:
> > 
> > Hi!,
> > if we use gtk_window_set_geometry_hints to set "aspect ratio" bound in gtk
> > programs, it didn't work in icewm.
> > Problem seems to be overflow in wmclient.cc's code.
> > Following patch works for me.
 
> Hmm. I don't like to use floats here. They could lead to some
> rounding problems.  

If you avoid division, then you should do at least as well
with doubles as with ints. A double can exactly represent any 
integer on most platforms.

> IMO gtk+ is stupid here.

Stupid, no. Unwise, perhaps. If for no other reason than
it does break WM's. (Not just IceWM, but also, as I discovered
recently, fvwm and twm have problems with overflow)

> There is absolutely no
> sense in using numbers larger than 32767 (max window
> width/height).

As a random example, say that the app wanted to set a 
maximum aspect ratio of the golden ratio:

 (1 + sqrt(5))/2              = 1.618033989...

Currently, GTK+ uses:

 214783647/1327217885         = 1.618034024...

If confined to 16 bits, you could use:

 65536/40503                  = 1.618052984...

So, is a window size of 610 x 377 OK? 

 610/377                      = 1.618037135...

Currently, yes; sticking to 16 bits, no. So it does
make a difference. Will the user care about the 1
pixel one way or the other? Almost certainly not.

> Perhaps some normalization could be done.  Why is gtk using such
> large numbers?

The interface that GTK+ exports to applications 
has the aspect ratio as a floating point number. GTK+
needs to approximate this as a ratio to pass to the
WM. It does:

      if (geometry->max_aspect <= 1)
	{
	  size_hints.max_aspect.x = G_MAXINT * geometry->max_aspect;
	  size_hints.max_aspect.y = G_MAXINT;
	}
      else
	{
	  size_hints.max_aspect.x = G_MAXINT;
	  size_hints.max_aspect.y = G_MAXINT / geometry->max_aspect;;
	}

For the next release of GTK+, it looks like I need
to trim down that G_MAXINT to something kinder
to window managers.

Of course, you could do considerably better by picking
rational approximations without a fixed denominator,
but that, I think, would be decided overkill...

Regards,
                                        Owen