[Cuis] differences between Cuis and Squeak and Pharo

[Casey Ransberger]

Hi David. I'll try to answer as many of your questions to the best of my ability; I will appreciate corrections from others on the list if I get anything wrong. 

Inline. 

> On Aug 20, 2014, at 7:15 AM, Davide Della Casa <davidedc at gmail.com> wrote:
> 
> Hi,
> 
> I’m working my way through Cuis code…
> 
> I start to see some patterns emerging, and it’s clear that design philosophy is minimal and "clean".

That's the idea, yes:) and to the end that an elegant system lends itself to personal mastery better than a large system with decorations all over it. 

> I’ve read the discussions around the class count being kept to a minimum compared to Squeak and Pharo, and the Morphic 3.0 approach being about "multi-scale" and best-of-class anti-aliasing solutions, and the philosophy of keeping the core to a minimum.

That's all consistent with my experience here yes. 

> I’m wondering whether there is a more detailed summary of what has been taken out and refactored and re-architected in respect to Squeak and Pharo?

First off, don't assume it was all "taken out" by us: in fact many things (e.g. Traits and EToys) were never loaded into Cuis in the first place, as Cuised diverged some time back during Squeak 3.x IIRC. OTOH, Juan has also incorporated a lot of great stuff from Squeak trunk as well. So it's not so straight forward. 

> And I mention this because it’s the kind of thing that is difficult to do for a newbie like me, cause one would need to have some in-depth knowledge of Squeak and Pharo and Cuis, and yet it would be really cool to have this map and go “ah I see, this is available just like in the Squeak examples I’ve seen but I need to plug it from a package in because the core can do without it…, and look this part is so much cleaner with two classes I can do what I needed to do with five”. Also this could be a really useful map for people who would like to know how to migrate code/packages from one system to Cuis, so it would be useful well beyond newbies actually…

There isn't a map. Even if such a thing were desirable, I think it would be premature to write that book. Cuis is a planet that hasn't quite cooled yet. It's evolving a lot. 

One general rule of thumb might be, you'll have to rewrite most Morphic code from other systems to make it work here. With the rest of the code it depends. "Vanilla" Smalltalk code often cares less which fork it runs on, but stuff with heavy dependencies on parts of Squeak/Pharo which are not absolutely essential to the operation of the system may need heavy porting. 

> This is what I know so far in terms of comparisons by reading online:
>   - core class count (much lower than other two systems, core kept to a minimum)

Yep. 

>   - morphic 3.0 is scale-agnostic

And is vector-based. That's why it's scale agnostic. And it's coming soon, I think. 

>   - rotation of morphs in Cuis is not part of core (is it part of another package?)

Wrong. It was removed because Squeak's rotation is raster-based, and we're going to do it with vector graphics. See also, Morphic 3. 

>   - line morphs in Cuis are plug-in

Not sure about this one off-hand. Juan?

>   - layouts in Cuis are minimal (can’t make comparison here, don’t know enough about the other systems but I know that Squeak needs a number of other classes)

Yes. One thing I'd like to see us do later is WYSIWYG layout controls from e.g. the halo. But yes, layouts in Cuis have been simplified. 

Another thing to note is that coordinates in Cuis are relative to the parent morph, not the world. This is also to support a scalable UI. 

>   - list of main Cuis packages and repos
> 
> I wonder whether there are more deltas that can be highlighted… some come to mind but ideally one would want to have a larger list… for example I’d love to know:
>   - approach to naming, are there major classes/methods that are the same but follow a different naming convention?

Not usually. It's common to see classes with far fewer convenience methods in Cuis. Juan prefers to create new selectors rather than reuse the old ones when the behavior has to change a great deal. Don't quite me on my example because it's from memory, but #position in Cuis became #morphPosition for this reason.

We use the left arrow (underscore) consistently in the core system for assignment, whereas authors of external packages are left to make their own decisions about that. 

>   - are all the main morphs still there in the same hierarchy structure? What are the differences?

Only the most essential Morphs generally are a part of the core of Cuis. The hierarchy of the system is likely to be very similar, with some nodes in the hierarchy removed (e.g. we don't have thirty kinds of buttons or anything like that.)

>   - is the event system and the re-paint code similar?

Not my department. I think Juan wrote a nice summary of of the differences between the various flavors of Morphic some time back. 

>   - traits being used or encouraged?

Nope. 

>   - text/fonts, are those the same approach?

The font system in Squeak trunk, last I checked, was from Cuis. 

>   - main tools in the vanilla environment: different/same?

We have less tools in the core than Squeak does (e.g. no dependency browser, etc) but all of the classic ST-80 tools are included. 

>   - menus structuring: different/how?

Different? Totally different. How? Partly me:) one concern we have in Cuis is small screens (on general DynaBook principle and because the first two contributors are fond of tiny laptops,) and as such the world menu is much less monolithic. 

I also added a bunch of icons to everything. They were from the Tango icon set. One place we could really improve things throughout the user experience is by replacing the Tango icons with some new ones designed to better fit the Smalltalk experience (e.g. currently we have a terminal icon for the workspace, which really isn't appropriate.)

>   - other parts that have been taken out completely or put in a package?

I think everything that has been made into a package by Juan is in the Git repository. So you can see that stuff. There isn't a catalogue. 

One fun experiment might be to write a workspace expression that makes a dictionary out of the structure of all of the classes in the system, their class and instance methods, their implementations (I'd go with byte code to rule out stuff like assignment, white space) and then compare the resulting dictionaries from the different forks. Because you can do stuff like that !

> Cheers,
> Davide

Hope I helped a little,

--Casey

> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20140821/a3397654/attachment-0004.html>