Advice on Mix and Match: squeak, cuis, magma, bobsui, maui

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.

Hi Ross -

Squeak 4.1 includes the Cuis editors and they are enabled by default. In
Squeak 4.1 you can actually switch the editor to use (mostly just so
that we have a fallback if something goes horribly wrong):

        "The old ParagraphEditor hierarchy"
        TextMorph defaultEditorClass: TextMorphEditor.

        "The Cuis editor hierarchy"
        TextMorph defaultEditorClass: SmalltalkEditor.

In other words, choosing the Cuis editors as the basis is exactly the
right thing to do and should work in Squeak 4.1, 4.2 and Cuis.

Cheers,
   - Andreas

On 9/1/2010 10:16 PM, Ross Boylan wrote:

On Wed, 2010-09-01 at 22:32 -0700, Andreas Raab wrote: I believe the Cuis editors in squeak were based on a version of Cuis
after the inheritance of classes from MVC was eliminated, but before the
machinery was changed over to rely exclusively on Morphic.  So the
actual operation remains substantially MVC.

For  example, the released squeak 4.1 image has the "cuis" editor
SmalltalkEditor a subclass of Editor.  The initialize method of that
class says
        sensor := InputSensor default
and the code uses that sensor extensively.  So the class no longer
inherits from MVC, but it still relies on MVC for many of the internals
of operation.  And it makes relatively little use of the Morphic
protocols for handling and managing events when it gets to managing the
actual editing.

In contrast the latest Cuis image (2.6) has none of that, using morphic
protocols instead to manage and get keystrokes and other events.

Ross

On 9/2/2010 12:05 AM, Ross Boylan wrote:
Oh, that is true, I hadn't even noticed. I wonder how difficult it would
be to merge that in Squeak, it looks like a nice improvement!

Cheers,
   - Andreas

Hi Ross,

You did a great analysis of the situation and issues involved. (more
interleaved)

On 02/09/2010 02:16 a.m., Ross Boylan wrote:
You're absolutely right.

As Andreas said in another response to this thread, the reason is not
that the merge is hard. It is essentially because nobody attempted to do
it. I believe that the effort already done to switch to the new editors
(reorganizing the hierarchy and clean it of the Controller protocol) is
bigger than the next step (remove direct use of Sensor). So, merging
this into Squeak is advisable and not that 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.

Getting Cuis to load MC packages is almost trivial. First, it shouldn't
be hard to make MC run on Cuis. I've ported many packages to Cuis and
usually you just need to adjust for slightly changed protocols. This
means that most packages don't seem to need the huge amounts of code I
removed from Cuis.

But there's another alternative. Just add the .zip extension to the MC
package file, unzip with any zip tool, and look for the
snapshot/source.st file. You can load and/or study that code with the
tools already in Cuis. That's what I usually do, as I never needed to
actually save an MC package from Cuis.

Then you have the second issue, compatibility issues. I don't expect
major problems in Magma. But BobsUI or any other widget framework might
rely on Morph protocol or features that I modified or removed. That's
the price to pay for a simpler system! As you are interested in making
your own widgets, and not just asking for everything to work without
wanting understanding it, I guess you can deal with it and enjoy it. It
shouldn't be that hard anyway for somebody that understands Morphic.

BTW, I'll do a new release of Cuis this week, that includes a new, very
simple LayoutSpec class and machinery for laying out morphs, done
specifically for end-user applications. That alone, with the big
simplification of the layout code it brings, might be enough reason to
choose Cuis.

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

Yes. You should take advantage of simplified and cleaner code in Cuis,
either through alternative 1 or 2.

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

I'd go with 2, but my opinion might be biased :). Cuis is a bit
addictive. It gives you great control over everything. You lose the fear
of touching the unknown parts of the system. Once you get used to it,
you don't want to go back to the big Squeak image.

> 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.

Actually, if you did alternative 1, that would make you a core
contributor of that effort.

Cheers,
Juan Vuletich

On 02/09/2010 04:05 a.m., Ross Boylan wrote:
Well, it doesn't rely on MVC, the Cuis version with that code had no
traces of MVC left. But it does rely heavily on Sensor, as you say. That
was cleaned in later versions of Cuis.

Right.

Cheers,
Juan Vuletich

On Thu, 2010-09-02 at 07:39 -0300, Juan Vuletich wrote: ....... That sounds encouraging.  However, such a merge might involve several
layers of issues.  The first is getting the basic text editing switched
over.  That's the main thing I'm concerned with, and that may be what
you were thinking of when you said it was not that hard.  Even there,
the work would need to be extended to handle Unicode.  Second, this
might disrupt various tools, in particular ToolBuilder.  Third, since
the current auto-completion framework uses the old text editing
framework, it seems likely it will break.  Perhaps, at least as a
transitional thing, it could continue to use the old code.

The work Juan has done simplifying the editors is absolutely fantastic,
and I'd like to publicly thank and congratulate him.  While the
completion framework shows that some people have been able to comprehend
and extend it, I think the new code is much easier to understand and
extend.

Ross