Re: icewm: patch about aspect ratio

Marko Macek <> 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'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;
	  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...


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]