Sean
this is years since I clean Morphic (may be I’m that good at it) but this is
important to
go step by step. So I would really like to get a list of simple actions.
Do you have an idea?
For example I have
remove extract update conditional leaves into method,
remove update/changed from leave morph.
in your list you have items that should be first validated by an experience.
And it would be good to distinguish them from the others.
> Pharo4Stef wrote
>> I’m trying to understand how we could work together to share forces on
>> cleaning morphic.
>
> Yes, this will be my focus for 4.0 and I've been thinking a lot about it.
> I've spent the last few weeks studying Cuis, Self, and the L and KS stuff
> from vpri.
>
> These are some of the experiments I want to do:
> 1. infinite world a la Self
> 2. remove all global references i.e. ActiveWorld, World, and ActiveHand
> 3. possible remove the concept of mouse and keyboard focus entirely. This is
> what Self does and it seems much cleaner. There would just be mouse and
> keyboard subscribers and a Morph, let's say a text editor, would "take focus
> away from itself" e.g. when there was a mouseDown outside it's bounds
I do not know
> 4. Local co-ordinates
We talk with Alain and Nicolas and one idea could be to introduce a Morph in
Bloc (composite)
that has local coordinate but still offer a global computation so that we can
slowly migrate code to the local
> 5. Simplified layouts (maybe based on Cuis or Lesserphic)
> 6. Cuis CPU-saving UI loop
> 7. Direct Morph construction leading to e.g. Spec models
I did not get 7
Remove update:/changed:
>
> I don't think the cross-cutting problem will be so bad because there doesn't
> seem to be much work at this low-level. So our slices will go stale, but
> should be easily merge-able.
>
> I think the safest way to proceed would be:
> 1. Hypothesis - write up our ideas about how Morphic currently works
> 2. Experiment - write tests for the current behavior
> Once we have a theory about existing Morphic, we can repeat. e.g.
> 3. Hypothesis - coordinates should be local to owner Morph
> 4. Experiment - pick a Morph far from core i.e. nothing used in development
> tools and apply. See how it works, if it makes things more clear
> Now hopefully we'll have a theory that local coordinates will improve the
> system, and we apply it to the whole system:
> 5. Set up a hook to easily plug the new behavior in and out. e.g. (pseudo
> code)
> NewClass class>>#enable
> Smalltalk at: #ExistingClass put: NewClass
> NewClass class>>#disable
> Smalltalk at: #ExistingClass put: OldClass "where OldClass is a class
> var"
> Maybe we can even put an error handler in the UI loop so that errors
> automatically unplug the new code.
>
> Anyway, just some preliminary ideas...
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/process-to-collaborate-on-cleaning-morphic-tp4739325p4739493.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>
