Subject: [[email-masked]: [gtk-list] Re: A question about box packing and widget/window sizing..]

From: Matthias Clasen <[email-masked]>
Date: Mon, 3 May 1999 16:57:08 +0200

I just saw this on the gtk list. I claims that fvwm's aspect ratio
calculations are wrong. 

Matthias

------- Start of forwarded message -------
Resent-Cc: recipient.list.not.shown:;@redhat.com
MBOX-Line: From [email-masked]  Mon May  3 10:58:07 1999
To: "Daniel J. Kressin" <[email-masked]>
Cc: [email-masked]
Content-Type: text/plain; charset=us-ascii
From: Owen Taylor <[email-masked]>
Date: 03 May 1999 10:27:24 -0400
In-Reply-To: "Daniel J. Kressin"'s message of "Sun, 2 May 1999 23:55:53 -0500 (CDT)"
User-Agent: Gnus/5.07008 (Pterodactyl Gnus v0.80) Emacs/20.3
Resent-From: [email-masked]
Reply-To: [email-masked]
X-Mailing-List: <[email-masked]> archive/latest/5616
X-Loop: [email-masked]
Precedence: list
Resent-Sender: [email-masked]
X-URL: http://archive.redhat.com/gtk-list/
Subject: [gtk-list] Re: A question about box packing and widget/window sizing..

"Daniel J. Kressin" <[email-masked]> writes:

> On 2 May 1999, Owen Taylor wrote:
> [snip]
> >
> >Note that your constraints actually constrain the possible sizes
> >of the toplevel window - so if you don't want to play some
> >game with the user of "no, you can't have that size", you
> >need to tell the window manager about the constraints.
> >
> [snip]
> >
> >I think the following should achive exactly the effect you
> >want:
> >
> > GdkGeometry geometry;
> >  
> > geometry min_aspect = 1.0;
> > geometry max_aspect = 1.0;
> >
> > gtk_window_set_geometry_hint (toplevel, drawing_area,
> >                               &geometry, GDK_HINT_ASPECT);
> >
> >The key here is the geometry_widget argument; if this
> >is non-null then the constraints refer not to the toplevel
> >as a whole, but to subwidget of the toplevel.
> 
> This doesn't work.  In fact it causes the following odd results:
> 1) Neither NULL nor a non-null value as the geometry_widget arg constrain
> the drawing area ("d_a") or the toplevel window at all.
> 2) Scenario: Executable W (with the above code), Executable WO (without 
> the above code), both running on (Linux) machine A.
>   Case 1 - Display on X server running on A:  WO gives the expected window
> contents, with no constraints on size.  W gives a window containing *only*
> the title bar (no packing table, no d_a), and what *would* be the
> background (gray rectangles) of the window, offset about -10, -10 relative
> to the "title bar window".  Any attempt to resize W results in a core dump
> with a BadAlloc. (It appears to be trying to alloc a backing pixmap
> roughly 65000 x -10 for some reason.)
>   Case 2 - Display on X server on a Win95 machine (Astec-X 2.12 trial): W
> and WO both display fine, with the expected window contents, again with no
> constraints on size.
> 
> Truly bizarre.  Any insights?

Sure. I investigated this bit, and found a number of things.

 1) For an aspect ratio of 1.0, GTK+ uses a ratio of 
    MAXINT:MAXINT. Although it's legal, it gives fvwm
    fits because of the way it does its calculations.
    (This is why you saw the weird effect where the contents
    popped out of the fvwm frame)

so, I changed that to 1000:1000, and found:

 2a) fvwm and twm get the aspect ratio calculations wrong anyways - 
    they don't take into account the base size fields and
    just constrain the overall window size to that aspect ratio.

 2b) WindowMaker also gets the aspect ratio calculations wrong for 
     a more amusing reason - it apparently switches 
     base_width and base_height somewhere in its calculation.

It sounds like the Astec X server might not obey the 
aspect ratio hints at all.

Enlightenment does get it right, so there are window managers
that will produce the desired effect; though there are a couple
of GTK+ quirks that you have to take care of; the notable
one being that you need to specify a base size as well
as the aspect ratio.

the conclusion of all this is that you probably are
best off not using this tactic ;-)

As an alternate suggestion, try putting your drawing area
inside a GtkAspectFrame. That was my very first GTK+
widget, and designed for almost exactly this purpose.
It won't constrain the size of the toplevel window, but
the drawing area will be a square inside of whatever
area it gets in the end.

Regards,
                                        Owen

- -- 
To unsubscribe: mail -s unsubscribe [email-masked] < /dev/null
------- End of forwarded message -------

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
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: Bob Woodside <[email-masked]>
Date: Mon, 03 May 1999 14:37:47 -0400

>     popped out of the fvwm frame)

	Ouch! That will definitely produce generally unattractive results. I'll
look into this, but I'm not familiar with the code. Does anyone recall
who last tinkered with the aspect ratio stuff? I know it had some fixing
done for 2.2.

>     just constrain the overall window size to that aspect ratio.

	From a quick glance, it looks as though the code in GetWindowSizeHints
doesn't follow its own comment:

   * ICCCM says that PMinSize is the default if no PBaseSize is given,
   * and vice-versa.

It does the first, but not the vice-versa. It seems to give preference
to PMinSize and PMaxSize, whereas I believe it's supposed to be to other
way around (i.e., PBaseSize should take precedence).

> that will produce the desired effect...

	Well, then we definitely need to clean this up!  :-)

> though there are a couple

	Matthias, are you continuing to follow this thread on the gtk list? Did
they decide to try another approach to get around the problem (of
course, we should fix it anyway)?

- Bob

---

From: Dan Espen <[email-masked]>
Date: Mon, 03 May 1999 15:01:35 -0400

> who last tinkered with the aspect ratio stuff? I know it had some fixing

I don't remember any fix in the 2.2 time frame, other than the fixup
in FvwmIdent to get the information to display.  There was a problem
that came up where we SUSPECTED aspect ratios.  It was some other cause.

Back around  2.0.47c, Chuck dealt  with the ratio being illogical, Ie.
the minimum and maximum being reversed by the application.  Other than
that, I think this is virgin code.

I don't think MAXINT/MAXINT is correct, any more than I think "4/1" is
the correct answer for 2+2, but I suppose we will deal with it.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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: Bob Woodside <[email-masked]>
Date: Mon, 03 May 1999 17:41:07 -0400

> that, I think this is virgin code.

	How time does fly! That's the fix I was thinking of.

> the correct answer for 2+2, but I suppose we will deal with it.

	I'm inclined to agree. However, since this is a ratio, the numbers
don't really represent a window size, and MAXINT/MAXINT should be
understood as equivalent to 1/1, if I'm reading the X doc correctly. I
think the algorithm here needs a little tweaking and, um, robustifying.

- Bob

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 4 May 1999 03:22:03 +0200

>     just constrain the overall window size to that aspect ratio.

Does the author of this mail want to say that the aspect ratio
should be calculated from (currend dimensions minus bas dimensions)?
This is wrong, of course.

> aspect ratio hints at all.

Which would be perfectly legal.

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: Tue, 4 May 1999 09:14:16 +0200

> This is wrong, of course.

No, I was surprised to find that this is exactly what the ICCCM
demands:

http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.3

to cite:

The min_aspect and max_aspect fields are fractions with the numerator first and the denominator
second, and they allow a client to specify the range of aspect ratios it prefers. Window managers that
honor aspect ratios should take into account the base size in determining the preferred window size. If a
base size is provided along with the aspect ratio fields, the base size should be subtracted from the
window size prior to checking that the aspect ratio falls in range. If a base size is not provided, nothing
should be subtracted from the window size. (The minimum size is not to be used in place of the base size
for this purpose.) 

Matthias

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 4 May 1999 09:40:44 +0200

> should be subtracted from the window size. (The minimum size is not to be used in place of the base size

?? But that's utter nonsense. This won't work at all if the window supplies
minimum dimensions that are smaller that the base dimensions. And what is the
aspect ratio when the window size didn't change? As far as I know zero divided
by zero isn't even defined. I think we should ignore this. Other folks must
have some experiences with this too. Any ideas whom to ask?

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [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: Tue, 4 May 1999 09:56:11 +0200

> aspect ratio when the window size didn't change? As far as I know zero divided

I guess this places the implicit constaint on the WM_NORMAL_HINTS that
the base dimensions must be strictly smaller than the minimal dimensions.

> have some experiences with this too. Any ideas whom to ask?

The source of Enlightenment, since it was said to get this "right" ?!

Matthias

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 4 May 1999 10:36:44 +0200

> the base dimensions must be strictly smaller than the minimal dimensions.

Er, that would imply a window manager had to make the window smaller
than its minimum dimension when initially mapping it when min and base
dimensions are given (and base < min). Conclusion: min and base
dimension *must* be the same which is pretty useless.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 4 May 1999 10:41:45 +0200

> dimension *must* be the same which is pretty useless.

Matthias, could you bring up this topic on the gtk mailing list?
I think we need some clarification here.

Bye

Dominik ^_^

---

From: Bob Woodside <[email-masked]>
Date: Tue, 04 May 1999 09:24:21 -0400

> Which would be perfectly legal.

	And, I would think, required. I didn't quite folllow this part of
the original post. My understanding of these hints is that they're for
the window manager, not the X server (whose job is not to enforce
policy, but just to do what it's told).

- Bob

---

From: Bob Woodside <[email-masked]>
Date: Tue, 04 May 1999 09:24:40 -0400

> > the base dimensions must be strictly smaller than the minimal dimensions.

	Which condition FVWM will currently override, and force the minimums to
1. This is the area that I thought looked suspicious.

> dimension *must* be the same which is pretty useless.

	I don't think the conclusion is correct: it would be nonsensical, if
so. My trusty old O'Reilly, Vol 1 (12.3.1.3), says

=>  The base_width and base_height fields if set are used instead of
min_width
=>  and min_height. If they are not set, min_width and min_height are
used.

	To me this says that there is no relationship, express or implied,
between the two. If the base width & height are supplied, the min_width
and min_height should simply be ignored (if set, although section 3.2.8
says that you shouldn't set both).

	That said, I can't help wondering whether the code that decides that
the hints are broken if base_w/h are smaller than min_w/h was written
that way because somebody encountered some buggy apps that behaved badly
if the rules were followed as I understand them.

	----------------------------------------------------------------------

	All of this has absolutely nothing to do with the aspect ration of a
window - say 8/5, or 1280/1024 - which leads me to agree with Dominik's
characterization of the statement in the ICCCM as nonsense. I don't see
the point in subtracting the base size from the window size, which could
lead to nonsense. Is there something subtle that we're both missing?

- Bob

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 4 May 1999 15:52:48 +0200

> says that you shouldn't set both).

Isn't the base size meant to be the size the application prefers to
be started with and the minimum size simply the lower bound? If not,
why should you have two size hints that mean the same and are mutually
exclusive?

> if the rules were followed as I understand them.

I can't quite remember what I did there recently. You should compare
the current code with 2.2 to get the differemces.

Bye

Dominik ^_^

---

From: Matthias Clasen <[email-masked]>
Date: Wed, 5 May 1999 00:20:43 +0200

> if the rules were followed as I understand them.

I think this is the case - and I have removed the code in question.
I can't find any constraint in ICCCM that would force base to be
between min and max - nor can I find any hint that base would be
the "preferred size" for the app to start with. This is simply not
true. The preferred size for the app to start up is the initial size
it gave to its window. Period.
   
> lead to nonsense. Is there something subtle that we're both missing?

I don't know if you are missing something, but it turns out that this
subtraction doesn't really lead to nonsense. The algorithm we use for
adjusting aspect ratios seems to work fine with window sizes <=0.
I have just committed a patch implementing it. 

Matthias

---

From: Matthias Clasen <[email-masked]>
Date: Wed, 5 May 1999 00:28:38 +0200

> why should you have two size hints that mean the same and are mutually

Where did y<ou get the idea that base size is "preferred initial size".
The ICCCM doesn't contain any hint in that direction.

Matthias

---

From: Matthias Clasen <[email-masked]>
Date: Wed, 5 May 1999 09:19:33 +0200

> The ICCCM doesn't contain any hint in that direction.

OK, now I found the section in the Xlib manual saying that "the base_width and
base_height members define the desired size of the window." 
But I really think this is in conflict with the description of these
values in the ICCCM. 

Even more so since the ICCCM also states that base size is the smallest
"good" one in the progression (ie the integers i, j should be nonnegative),
but I know of no wm which would enforce that. You can easily see fvwm
fail to enforce this by making base > min and watch negative values
appear in the size display when making the window small.

Matthias

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 5 May 1999 18:12:39 +0200

> appear in the size display when making the window small.

I must confess that I didn't have a look at the ICCCM until yesterday.
And after having a look I'm *shocked*. This lampoon isn't worth the
paper it's printed on. No wonder that there ase *so many* bugs in X
applications and window managers. Did these feolks really take ten
years to write a document of this superficial quality? Sigh! The ICCCM
doesn't even give hints about proper value ranges for the wm hints.
For example it's perfectly legal to have negative base dimensions, a
negative width_inc or an aspect ratio of -27/-871257431187324. All this
is guaranteed to create bugs somewhere. Enough ranting, I wanted to comment
on Matthias' patch:

I see what the point of subtracting the base dimensions is, but I still
think of it as problematic. I can't imagine more that 10% of applications
that define an aspect ratio want it interpreted this way. But there are
some technical aspects:

  1) If someone really uses negative values for the aspect ratio (and after
     seeing what gtk does I wouldn't be surprised), our inequations will fail
     because ( a > b ) <=> ( -a < -b ).

  2) This works only when we don't calculate the aspect ratios like this:
     (maxaspect_x/maxaspect_y) < ((width-basewidth)/(height-baseheight).
     (because of the possible division by zero). On the other hand things
     like using MAXINT/MAXINT will force us not to multiply with the
     denominators on both sides as we do now because the result of the
     multiplication will generate an overflow. So we'll have to switch to
     float arithmetic and thus lose quite some precision when big numbers
     are multiplied.

Bye

Dominik ^_^

---

From: Bob Woodside <[email-masked]>
Date: Wed, 05 May 1999 13:12:03 -0400

Dominik Vogt wrote:
> 
> I see what the point of subtracting the base dimensions is...

	I'm still missing it. Could you try to explain it?

> but I still think of it as problematic. I can't imagine more that 10%
> of applications that define an aspect ratio want it interpreted this
> way.

<rant>
	I can't imagine any. Unless the base dimensions and the initial window
size are integral divisors of the aspect constraint values (neither
mandated by the spec, nor very useful unless you want to maintain one
constant aspect ratio), then the resulting range of ratios is going to
be something other than what the app thought it was asking for.
</rant>

- Bob

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 5 May 1999 20:25:02 +0200

> 	I'm still missing it. Could you try to explain it?

Imagine this window:

  +----------+-----+
  |          |  X  |
  |          |     |
  +----------+-----+
  |Base      |     |
  |dimensions|     |
  |          |     |
  +----------+-----+
  current dimensions

The rectangle in the lower left are the base dimensions, the full
rectangle is the current window. The rectangle X shows the difference
between base and  current size. The given aspect ratio limits the
dimensions of X. If you have an aspect ratio of x / y this is an
instruction like this:

  If you add x to the width you have to add at least y to the height too.

Now think of the base dimensions as the decorations part of a window and
the additional size as the useful working area. E.g. if you have xemacs
the base size would be the space needed for menus, scrollbars and the
modeline while the additional size is the size of the text area. When
resizing the decorations dont grow. They still use the same amount of
space. So the aspect ratio would be applied to the text area only which
might be useful with some applications (e.g. when you want to display
a chess board).

But unfortunately the ICCCM says nothing about the logic behind these
hints. A convention that simply states that there are hints but does
not explain what they are good for is pretty useless in my opinion.

Bye

Dominik ^_^

---

From: Matthias Clasen <[email-masked]>
Date: Wed, 5 May 1999 20:52:38 +0200

> 	I'm still missing it. Could you try to explain it?

One application for the base size subtraction I could think of is
the following: constraining the aspect ratio of a subwindow.

Imagine your window has the following layout

+----------------------------+
|             M              |
+--+-------------------------+
|  |                         |
|  |                         |
|  |                         |
|  |                         |
|T |          D              |
|  |                         |
|  |                         |
|  |                         |
|  |                         |
|  |                         |
+--+-------------------------+

where 
M has a fixed height h (eg menubar)
T has a fixed width w (toolbar)
D should have an aspect ratio between x1/y1 and x2/y2

This can be achieved by setting the base_size to (w,h)
and the aspect ratios to x1/y1 and x2/y2

you would of course set min size to base size + minimal useful
size of D, thus the subtraction won't lead to problematic values.

Matthias

---

From: Matthias Clasen <[email-masked]>
Date: Wed, 5 May 1999 21:11:23 +0200

>      because ( a > b ) <=> ( -a < -b ).

I  have updated my patch to revert to the old behavior unless base <= min.
This should avoid problems with negative values and 
also give most applications which follow the (misleading) Xlib
manual and put the preferred size in base the desired behavior.

>      like using MAXINT/MAXINT will force us not to multiply with the

To cater for this, I normalize the aspect ratios now. So MAXINT/MAXINT will
be reduced to the rather harmless 1/1.

>      float arithmetic and thus lose quite some precision when big numbers

Enlightenment does it this way, so we must do it better :-)

Matthias

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 5 May 1999 23:57:35 +0200

> be reduced to the rather harmless 1/1.

That won't help if some joker uses MAXINT/MAXINT-1, of course.

> Enlightenment does it this way, so we must do it better :-)

:-)

Bye

Dominik ^_^

---

From: Bob Woodside <[email-masked]>
Date: Wed, 05 May 1999 23:22:22 -0400

Matthias & Dominik wrote:
DV > Imagine this window: ...
MC > One application for the base size subtraction...

	Matthias, Dominik -- thanks for your explanations. The dim one finally
begins to see a light. 

MC > ...applications which follow the (misleading) Xlib manual...

	To say the least!

MC > To cater for this, I normalize the aspect ratios now. So
MC > MAXINT/MAXINT will be reduced to the rather harmless 1/1.

	This and the divide-by-zero situations were really my main concerns. I
never realized there was so much ambiguity surrounding tthe meaning of
the base sizes - never thought much about them at all, actually. (I
still think they're fairly useless unless they function as an
alternative way of expressing the minimum useful size, rendering the min
sizes superfluous when they're used.)

MC > Enlightenment does it this way, so we must do it better :-)

	What, you mean with float math? Gack!

DV > That won't help if some joker uses MAXINT/MAXINT-1, of course.

	Yeah, I'd thought about that one (and I'm sure someone will try it
someday!) This is easily enough handled by just converting these to
their absolute values.

DV > ...FvwmIconMan sets min_width to zero. I think we should
DV > tolerate this way of saying 'don't care'.

	I think this is reasonable...though for ease of debugging we might want
to leave the lines that flag broken hints #ifdef'ed around for a little
while. There are probably a lot of people writing apps who think they're
*supposed* to set these, even though they don't care, and just set them
to 0.

- Bob

---

From: Tim Phipps <[email-masked]>
Date: Thu, 06 May 1999 09:03:03 +0100

> sizes superfluous when they're used.)
The base sizes are very important when you have resize increments larger
than 1. An xprop on an xterm gives me:

                program specified minimum size: 25 by 16
                program specified resize increment: 6 by 12
                program specified base size: 19 by 4

The 4 is for the two pixel border around the window, the 19 is for the
border plus a 15 wide scrollbar. Subtracting these from the min size
gives a 1 by 1 window (in resize increment terms). If you didn't have a
base size to fudge in the border would have to be zero width (which
looks bad) and the scrollbar would have to be a multiple of the
character width.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 6 May 1999 11:25:49 +0200

> someday!) This is easily enough handled by just converting these to

Our calculations will overflow the integers.

Bye

Dominik ^_^

---

From: Matthias Clasen <[email-masked]>
Date: Thu, 6 May 1999 15:36:14 +0200

> That won't help if some joker uses MAXINT/MAXINT-1, of course.

We could do even more normalization by finding a nearby fraction
with bounded numerator and denominator... but is that really needed ?

Matthias

---

From: Dan Espen <[email-masked]>
Date: Thu, 06 May 1999 09:44:02 -0400

> with bounded numerator and denominator... but is that really needed ?

In my opinion, all thats needed is:

 if (aspect_x == aspect_y) {
  aspect_x = 1;
  aspect_y = 1;
 }

---

From: Matthias Clasen <[email-masked]>
Date: Thu, 6 May 1999 15:49:32 +0200

>  if (aspect_x == aspect_y) {

A special case of my proposal, but you are probably right that it is
enough.

---

From: Bob Woodside <[email-masked]>
Date: Thu, 06 May 1999 21:04:46 -0400

Tim Phipps wrote:
> 
> ... An xprop on an xterm gives me:
> 

	Hmm...this may be the most enlightening example of all. Thanks.

- Bob

---

From: Bob Woodside <[email-masked]>
Date: Thu, 06 May 1999 21:04:56 -0400

Dominik Vogt wrote:
> >       Yeah, I'd thought about that one...
> 

	That's all right, Bob, you can go back to sleep now. Obviously I didn't
look at this long enough for my eyes even to focus, much less fully
engage my brain, so what registered was MAXINT/-MAXINT.

- Bob