Subject: size hints/gtk

From: Matthias Clasen <[email-masked]>
Date: Thu, 6 May 1999 17:18:31 +0200

I just saw the following mail from Owen Taylor 
on the gtk-devel mailing list. It explains that current gtk will always have x
or y equal to MAX_INT in the aspect ratio fields, but that they are going to
lower this to reduce wm breakage. 

Matthias

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg

Marko Macek <[email-masked]> 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

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 15 May 1999 00:34:36 +0200

> lower this to reduce wm breakage. 

I've lost track of this one. Will fvwm still freak out if it's
presented extremely large values?

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Matthias Clasen <[email-masked]>
Date: Sat, 15 May 1999 21:33:09 +0200

> presented extremely large values?

No, I have inserted some math in GetWindowSizeHints to
reduce the aspect ratio values to <= 2^16. This should be
enough to avoid overflows in ConstrainSize while keeping the
floating point math out of ConstrainSize.