[squeak-dev] Advice on Mix and Match: squeak, cuis, magma, bobsui, maui

Juan Vuletich juan at jvuletich.org
Thu Sep 2 10:39:11 UTC 2010


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

You're absolutely right.

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

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



More information about the Squeak-dev mailing list