[plt-scheme] wrap editor% ?

Am Montag, 04.11.02, um 03:50 Uhr (Europe/Berlin) schrieb David 
Richards:

>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> Hi all,
>
> How might one best achieve the following GUI effect in MrED?
>
> Consider an outer editor frame containing snip1 and an editor-snip 
> containing snip2:
>
> [snip1 [snip2]]
>
> (The square brackets are meant to indicate a container.)
>
> Add more snips:
>
> [snip-1 [snip-2 snip-3 snip-4 ... snip-n]]
>
> The inner editor will soon exceed the max-width of the outer 
> container. If auto-wrap is enabled for the outer container, the inner 
> editor-snip will wrap to the next line:
>
> [snip-1
>  [snip-2 snip-3 snip-4 ... snip-n]]
>

I'm looking for a quite similar functionality. So far, I have only 
implemented some basic helper routines for easier embedding of text% 
editors and searching them but not the automatic resizing. For a 
general way to wrap internal editors, I guess there must be a way for 
an editor to tell its "parent" editor how large it should become, 
wether it is supposed to wrap and wether it has to resize at all. You 
want editors to have a fixed size and wrap accordingly, I want editors 
to stay on the same line but grow or shrink:

[editor1
  [editor2 editor3] <== one line of an embedding editor1
]

now when editor1 is resized (the main dialog is resized), e.g. editor2 
should stay the same while editor3 should resize accordingly, or vice 
versa -- user defined. Perhaps we should look for a general way to get 
both kinds of functionality. I think we'd need some layout property in 
a text% subclass, like a symbol in '(no-resize resize auto-wrap), and 
we need a function to determine which embedded editors are on one line 
of the parent editor. Then a resize function would need to recursively 
descend into all embedded editors and compute their new sizes according 
to their layout specifications (from left to right editor) and the 
parent editor's new size.

For your convenience, here's a brief summary of some answers to a 
similar question by me:

Matthew Flatt wrote:

> When an editor-canvas% is resized, it calls the `on-display-size'
> method of editor it's displaying (if any).
>
> So your top-level text% is notified of the size change. Nothing in the
> base text% class propagates that message to embedded editors, though.
> You'll have to set that up yourself.
>
> When you figure out which editor needs to be resized (i.e., it's min-
> and max-width needs to be adjusted), finding the right size is tricky.
> I'm certain that it's possible, though. Robby may be able to point you
> to an example in the DrScheme implementation.
>

Robert Bruce Findler wrote:

> Indeed. I'm not sure what the context is, but one example: when you
> resize the drscheme frame, the boxes containing purple text (what went
> to stdout) need to resize. That code is in the wide-snip-mixin in
> plt/collects/framework/private/canvas.ss. Let me know of you have any
> questions.
>
> At some point in the future, we should have a horizontal-pasteboard%
> and vertical-pasteboard% classes that operate like the
> horizontal-panel% and vertical-panel%, but manage editors. That might
> also be of interest too.

Regards,

Erich