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


> No, it's just got a lot of options. Try this, which works for me, though 
> it'll still wrap over-long lines (by changing autoFit, as I recall, you can 
> make it not resize vertically when it wraps):
[snip]
Nope, it starts out looking better, but if you type enough (imagine a
longish file path) it not only wraps, but starts displaying the text
outside the bounds of the parent. Odder, selecting can highlight even
further outside the parent area!
I added #autoFit: true and it made no very noticable difference.

As a strawman on what _should_ happen, I think the text should not wrap
at all, but scroll left as you type, leaving the last chars visible on
the extreme right of the morph. Cursor keys and mouse selecting should
work by scrolling left/right if needed. <CR> should map to #accept.

[snip]
> What else did you expect to happen when the Morph width changed? Ignoring for 
> a minute the way that you _want_ the scrollbars to work, this is no different 
> than a child RectangleMorph suddenly deciding that it wants to be an extra 30 
> pixels wide.
Not sure at the implementation level (I simply don't do UI stuff very
often - must be seven or more years since I even thought about making a
UI!) but I think I would expect the flop-out scroll bars to overlay the
morph to the left (or right I suppose in some cases) rather than move
the text morph to the right (and certainly not to simply move it and
overflow the parent bounds) just like the lists in a brower.

I'm stunned and amazed that we're having so much trouble with this;
there must surely be an easier way!

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Dreams are free, but you get soaked on the connect time.