[Cuis-dev] Is anyone working on Morphic-free Cuis?

[Hilaire Fernandes]

Hi Stephen!

Le 21/04/2022 à 20:00, stephen--- via Cuis-dev a écrit :
> Yeah, I’m still tracking Cuis, and loving the lack of bloat.

Indeed. Cuis is very agile to improve itself while remaining an 
understandable system for an human being. This is the reason I am 
porting DrGeo from Pharo to Cuis, I am close to the end of the effort.

> My issues with Morphic are that it’s not MVC and it’s not well-designed.

Morphic on Cuis (aka Morphic 3)  is a redesign from the basement to the 
attic. It is a better design than the original Morphic 2 system on 
Squeak. Two salient aspects: its coordinate system is relative to each 
morph, its classes are simpler. I did not even mentioned VectorGrpahic, 
okay I just did.

> First, views and controllers are merged, which hurts reusability of 
> components and hinders the development of new interaction methods like 
> multi-touch screens or voice input.

Oh, but you can move out the controllers from the Morphic view. This is 
what I am doing. I am not an expert on MVC so please correct me if I 
miss some key point. In DrGeo the controls of the mathematic items are 
done outside of their respective Morphic view.

Regarding the more traditional GUI part, we are using pluggable Morphs 
composed with the Cuis' Layout system. It is interestingly reusable. I 
am also interested in the new interaction methods you mentioned.

I don't see blocking point preventing you from using Morph with a MVC 
design.

>
> Second, the base classes (Morph et al.) are pretty heavy-weight; Morph 
> has 6 instance variables, and you’re up to 10 or more by the

Cuis is very agile and, if I understand correctly the policy of its 
community, is prone to deep refactoring if it improves Cuis simplicity 
and efficiency. And these are not empty words, a few weeks ago, Cuis 
Morph system has been through an important design in the classes 
hierarchy. The classes were not exactly shortened but split, joined, 
renamed for a better understanding 
(https://lists.cuis.st/mailman/archives/cuis-dev/2021-December/004649.html).

Your need for smaller Morph, if you decided to jump in Cuis to port your 
software, will be also an opportunity for the Cuis community to improve 
the system in this particular area.

Regarding your comment, there are 5 instance variables in Morph 'owner 
submorphs properties id privateDisplayBounds'. Next, this is all you 
need for the view of your music notation system. You see, we had these 
discussion several months ago for DrGeo as I also want the simpler Morph 
as possible. In DrGeo the view of the mathematics models (point, 
segment, etc.) are almost direct subclasses of Morph:


Now while observing the Morph class, there is a lot of stuff in there I 
don't need for the DrGeo math morph. It should be doable to have a 
KernelMorph with only the instance variables 'owner id 
privateDisplayBounds' and the reduced ad-hoc behaviors. That is 
something that may interest you too.


> time you get to the interesting classes.  This makes it hell on the 
> garbage collector for complex UIs (like music notation) where you 
> might have thousands of display objects on the screen, and want to 
> scroll or page quickly.

As a matter of fact, you can observe this video until the end. There are 
10'000 points (10'000 Morph drawings, each of two lines) and the canvas 
is zoomed/unzoomed, an object is dragged around.

https://twitter.com/GNUDrGeo/status/1515365208428007426

Your software and mine are sharing the same concept of canvas where you 
are composing music notation and I math objects.

Nevertheless, porting to any system, will be a substantial effort. But I 
guess you know that.

If you decided to jump in and use Morph, I will be happy to help you, in 
tips and code.

About Brick I don't know yet.

Hilaire

-- 
GNU Dr. Geo
http://drgeo.eu
http://blog.drgeo.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220422/cfb400d5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture%20d%E2%80%99%C3%A9cran%20de%202022-04-22%2012-37-36.png
Type: image/png
Size: 60048 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220422/cfb400d5/attachment-0001.png>