@begin(header)
author: ackerman@ics.uci.edu
show_author: ShowNone
author_organization: MIT
expiration_date: 06/25/93
last_modifier: ackerman@ics.uci.edu
last_mod_date: 07/02/91
mod_num: 2
@end(header)
@begin(M)
Date: 6 Apr 89 18:28:13 GMT
From: Benjamin Ellsworth
Organization: Hewlett-Packard Co., Corvallis, OR, USA
Subject: Re: Parent <-> child communications in widget trees

> As I understand it, when a resize event happens, the composite widget
> is supposed to communicate with its children on what it intends to do
> with them. ...

As I understand it, the composite widget *may* choose to communicate
with its children and negotiate new geometries; however, the composite 
is under no obligation to do so.  Because the composite has no 
opportunity to negotiate with its parent during the processing of a 
"resize event", the algorithms for negotiating with children can become
quite unwieldly.  Hence, although it is provided for, few, if any, 
composites initiate geometry negotiations with their children during a 
resize.

The society of widgets is not as egalitarian as one might wish.
@end(M)

@begin(M)
From: Paul Asente
Organization: DEC Western Software Lab
Subject: Re: Parent <-> child communications in widget trees

As Benjamin Ellsworth already said, a composite widget may consult its
children but is under no obligation to do so.

This was added so that widgets like pane could be more flexible. Sometimes
an entry is willing to make height/width tradeoffs.  A button box doesn't
care about its dimensions as long as it's big enough to hold all the
buttons.

A polite composite will consult the children.  Most currently don't.  And
even if it does consult the children it's under no obligation to pay any
attention to what they say.  Sort of like many families I know.
@end(M)

@begin(Q)
Date: 6 Jan 89 21:39:31 GMT

I have a question or two about geometry management. The interface we
are using has a form that contains three horizontally stacked text
widgets and another form at the bottom of the whole mess. In the bottom
form are a row of label widgets and two row of buttons. There are 10
buttons placed side by side.

What I want to happen is the that the size of the application is
controlled by the text in the largest button. That means I need to
make all the buttons the same size, and then make the text widgets the
same size as the form that encloses the buttons. My problem is that
I'm not sure how to do this properly. What I did was realize the
entire widget tree with mappedWhenManaged set to false. Once all the
widgets are realized I find the largest button and then set sizes and
positions of all the other widgets. When this is done I do
XtMapWidget(toplevel).  Is this the correct approach? If not what is a
better way to do it?

Another feature I would like that complicates things a little more is
have my text widget be a fixed number of lines in height instead of a
fixed number of pixels. Even if it is a hack under R3 to get the the
font a widget is using it can be done. I can then configure the widgets
to the new size. It get a little messy because the y coordinates of the
widgets below the current one are likely to change based on the number
of lines displayed. Any hints on a good way to do this?
@end(Q)

@begin(A)
Date: Wed, 11 Jan 89 18:55:04 EST
From: Chris D. Peterson

> ...has a form that contains three horizontally stacked text
> widgets and another form at the bottom of the whole mess. In the bottom
> form are a row of label widgets and two row of buttons. There are 10
> buttons placed side by side.

I assume that you mean vertically stacked labels?  If this is the case then
you may gain better behavior by using a vpaned widget instead of a form for 
your topmost widget in the tree.

> What I want to happen is the that the size of the application is
> controlled by the text in the largest button.

???

I assume you are trying to get this?

----------    ----------    ----------    ----------
| label  |    |  foo   |    |   a    |    |long one|    
----------    ----------    ----------    ----------

----------    ----------    ----------    ----------
| button |    | button |    | button |    | button |    
----------    ----------    ----------    ----------

----------    ----------    ----------    ----------
| button |    | button |    | button |    | button |    
----------    ----------    ----------    ----------


There is not currently a widget in the athena widget set that will
allow this to happen. (Editor's note: There is in the other widget
sets.)  I have found that an application widget that makes all
children the same width as the longest child will do the proper thing,
although it is a hack.  Make sure to tell all the buttons not to
automatically resize themselves.

> Another feature I would like that complicates things a little more is
> have my text widget be a fixed number of lines in height instead of a
> fixed number of pixels.

The "right" solution is to be able to specify the height of the text
widget in lines as well as pixels, but since the Athena text widget
does not let you do this you must either hack it in, or do something
like the following:

Specify a default font in an application defaults file, and the height
of the text widget (in pixels) that give you the number of lines that
you want.  This will work correctly as long as the user does not
change the font.  If he does he is also able to change the height of
the text widget so that it will look right.  The advantage to this
method is that is allows the user to display a different number of
lines than the default, (i.e this not as friendly, but more flexible).

@begin(M)
Date: Mon 24 Apr 1989 11:25:20 EST
From: David Rosenthal <dshr@sun.com>

Background for my reply:

	A client in general has no control over the geometry, stack
	order & location of its top-level window.  It can request the
	window manager to provide a particular geometry and location,
	but this may not be granted.  Clients must accept whatever
	geometry, stack order and location they are given.  The geometry,
	stack order and location of a top-level window may change
	arbitrarily at any time,  through user interaction with the window
	manager or by its autonomous operation.

[Editor's note:  text deleted here]

The real problem is that the toolkit doesn't seem to make Shell widgets
special enough.  Unlike other widgets,  they are subject to arbitrary
size change at any time through an agency that will not brook questions
or disagreement.

Clients which place too much importance on the geometry of their top-level
window are just badly designed.  A client should work correctly with any
top-level window geometry.  The toolkit should make this easy.

@end(A)


