I've been working on some personal projects for which I'd like to use
Magma and BobsUI.  Maui might be an alternative or supplement to BobsUI.
Additionally I want to make an autocompletion widget.

I would appreciate any advice or insights into the best way to combine
these elements.  Broadly, the choices seem to be
1. Start with squeak 4.1 and attempt to modify the text editing system
to match Cuis.  magma, maui (?) and bobsui all work in 4.1.  Work on
autocompletion after merging in the Cuis changes.

2. Start with Cuis.  Attempt to load the other elements, updating them
as necessary for compatibility.

3. Start with squeak 4.1.  Don't try to merge in Cuis, and build
autocompletion within the existing text framework.

For the autocompletion I'd much prefer to work with Cuis because of its
simplified, pure-Morphic text widgets.  Squeak and the auto-completers
in it for code have a hybrid approach in which most of the actual work
happens in the old MVC code.  Even the latest released squeak, which
incorporates some of the Cuis work (so that the interface classes are no
longer subclasses of MVC), still uses mostly the old machinery (e.g.,
Sensors).  I find the result overly complicated.

There are reports of BobsUI loading into squeak 4.1 (4.0?), after
adjusting for the text editor changes.  There is a report of magma
loading (not necessarily working) into Cuis.

BTW, the autocompletion I'm interested in is more like google search
(completion operates within a list of words or phrases) than the
e/ocompletion packages designed to complete smalltalk code.

Options 1, 2, and 3 above all seem to involve considerable work, of
unknown size.  The fact that the more recent Cuis work on text editing
is not in mainline (AFAIK) suggests the merge is not trivial(*) (1 is
hard).  

But Cuis doesn't support any advanced packaging scheme, and so loading
things like magma and bobsui into it may also be a challenge (2 is
hard).  The difficulty of loading other packages into Cuis is two-fold.
First, if package x is in a package of type y (e.g., Monticello), and
Cuis doesn't have y, that could be a problem.  Second, assuming one can
get the code into the image, the differences between Cuis and regular
squeak  may require further code changes in the code of x itself.

I know 3 (just use squeak and the existing text framework) is hard,
since that was the original route I took.

If anyone has any info, or even sense, of the work involved in the
different alternatives, I would love to hear it.

Thanks.
Ross Boylan

(*) However, perhaps it is simply on hold pending the general review of
how to incorporate Cuis work into mainline squeak that other threads
have discussed.