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