Ned Konz <ned at bike-nomad.com> is widely believed to have written:


> a _ Morph new
> 	color: Color white;
> 	layoutPolicy: TableLayout new;
> 	listDirection: #leftToRight;
> 	cellPositioning: #leftCenter;
> 	hResizing: #spaceFill;
> 	vResizing: #shrinkWrap.
> label _ StringMorph contents: 'label: '.
> textField _ TextMorph new contents: 'text field'.
> a addMorph: textField; addMorph: label.
> a openInWorld.
OK, on my image that makes something with the same problem I had before;
the text field is narrow and does not expand to fill the width of the
owner morph (and to be still more puzzling, the halo for the owner morph
suggests it is much narrower than either of the submorphs). Type into
the text field and you get wrapping immediately and the depth of the
composite grow, moving the label down to the vertical centre each time.
I need to avoid these somehow; what I want is a labelled single line
text entry view, or something very similar. Is there something wrong
with TextMorph? It's as if it weren't responding to layout messages
properly. Putting two StringMorphs together doesn't cause the problem
(but doesn't make for an editable filepath either!).

> 
> Why the fondness for AlignmentMorphs? They're more or less obsolete, you 
> know, since all the layout stuff got moved to Morph.
I discovered that last night after reading the 'controlling your
submorphs' article in the new copy of SqueakNews, but since an
AlignmentMorph is a (suppossdly) innocuous holder like a rectangle
morph, I don't imagine it causes any harm. Or does it?
> 
> > |a b|
> >
> > a _ AlignmentMorph newRow.
> > b _ AlignmentMorph newColumn.
> > b addMorph: PluggableListMorph new.
> > b addMorph: PluggableListMorph new.
> > a addMorph: b.
> > a openInWindowLabeled: 'foo'
> 
> Looks fine to me. I get two PluggableListMorphs, one above the other. Of 
> course, the "a" morph isn't doing anything useful there.
No, but it is illustrating the problem I'm having nesting things; it
seems like it really ought to be possible.

If you turn scrollbars back to flop-out, you'll see the very odd effect
of going from one ofthe lists to the other. It doesn't happen with fixed
scrollbars.
> 
> > or how about:-
> >
> > |a b|
> >
> > a _ AlignmentMorph newRow.
> > b _ AlignmentMorph newColumn.
> > b addMorph: PluggableListMorph new.
> > a addMorph: PluggableListMorph new.
> > a addMorph: b.
> > a openInWindowLabeled: 'foo'
> 
> Looks like what you'd expect. What did you think would happen?
Again, try with flop-out scrollbars... wierd.
[snip]
> Ah. I see the problem with the flop-out scrollbars (which I don't use). Your 
> best bet is to use the SystemWindow proportional pane support to hold 
> pane-like things (specifically, anything with a scrollbar), rather than 
> letting the Morph table layout handle them.
Trouble is that that prevents making nice composites and plugging them
in, which seems a pity. Surely this nesting stuff ought to work better?

All ideas gratefully received.

tim 

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
I smell a wumpus.