Definition of Cuis parts

> Hi Juan,
>
> Now that Squeak supports Environments I thought a little bit what it would
> take to load Cuis' Morphic and STE in Squeak. The minimum would be to define
> three logical parts of Cuis:
> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible
> with Squeak
> 3. Other (Applications, Tools, System, Support, Tests): neither needed by
> Morphic nor STE
>
> If we had defined these, then we would need to "just" file out the Morphic
> part and STE and file it in in a separate Squeak environment and do some
> fairly minimal compatibility changes, right? ;-)
>
> Seriously, I looked briefly at the class categories and came up with first
> rough separation. See below. Can you have a look? Do you see any obvious
> errors? Any categories in Core which are not needed by Morphic? Any
> categories in Core which are needed but are not reasonably compatible with
> Squeak? Any categories in Morphic which are optional for STE? Any categories
> in Other which are needed by Morphic or STE?
>
> Cheers,
> Bernhard
>
> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
> Balloon-Collections
> Collections-Abstract
> Collections-Arrayed
> Collections-Sequenceable
> Collections-SkipLists
> Collections-Streams
> Collections-Support
> Collections-Unordered
> Collections-Weak
> Compiler-Exceptions
> Compiler-Kernel
> Compiler-ParseNodes
> Compiler-Support
> Compiler-Syntax
> Kernel-Chronology
> Kernel-Classes
> Kernel-Magnitudes
> Kernel-Methods
> Kernel-Numbers
> Kernel-Objects
> Kernel-Processes
> Network-Kernel
> Package Support
> SUnit
> SUnit-Preload
>
> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible
> with Squeak
> Graphics-Display Objects
> Graphics-Files
> Graphics-Files-TIFF
> Graphics-Primitives
> Graphics-Text
> Kernel-Text
> Morphic-Basic
> Morphic-Events
> Morphic-Halos
> Morphic-Kernel
> Morphic-Layouts
> Morphic-Menus
> Morphic-Support
> Morphic-Tests
> Morphic-Text Support
> Morphic-Tools
> Morphic-Views for Models
> Morphic-Widgets
> Morphic-Worlds
> Shout-Parsing
> Shout-Styling
> UCompletion
> System-Exceptions Extensions
> System-Exceptions Kernel
> System-Files
> System-Object Storage
> System-Text
> System-TextAttributes
> Theme-Core
> Theme-Tests
> Theme-Themes
>
> 3. Other (Applications, Tools, System, Support, Tests): neither needed by
> Morphic nor STE
> Compiler-Tests
> GraphicsTests-Primitives
> Kernel-Tests
> KernelTests-Numbers
> KernelTests-Processes
> LinearAlgebra
> SUnit-UI
> Signal Processing
> Sound-Scores
> Sound-Synthesis
> System-Applications
> System-Archives
> System-Code Differ
> System-Compression
> System-Object Storage-Tests
> System-Support
> System-Tests
> Taskbar-Core
> Taskbar-Tests
> Tests-Exceptions
> Tests-Files
> Tools-Browser
> Tools-Changes
> Tools-Debugger
> Tools-Explorer
> Tools-File Contents Browser
> Tools-FileList
> Tools-Inspector
> Tools-Menus
> CollectionTests
> Tests-Bugs
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

> Hi Juan,
>
> Now that Squeak supports Environments I thought a little bit what it would take to load Cuis' Morphic and STE in Squeak. The minimum would be to define three logical parts of Cuis:
> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible with Squeak
> 3. Other (Applications, Tools, System, Support, Tests): neither needed by Morphic nor STE
>
> If we had defined these, then we would need to "just" file out the Morphic part and STE and file it in in a separate Squeak environment and do some fairly minimal compatibility changes, right? ;-)
>
>  

> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
> Balloon-Collections
> Collections-Abstract
> Collections-Arrayed
> Collections-Sequenceable
> Collections-SkipLists
> Collections-Streams
> Collections-Support
> Collections-Unordered
> Collections-Weak
> Compiler-Exceptions
> Compiler-Kernel
> Compiler-ParseNodes
> Compiler-Support
> Compiler-Syntax
> Kernel-Chronology
> Kernel-Classes
> Kernel-Magnitudes
> Kernel-Methods
> Kernel-Numbers
> Kernel-Objects
> Kernel-Processes
> Network-Kernel
> Package Support
> SUnit
> SUnit-Preload
>
> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible with Squeak
> Graphics-Display Objects
> Graphics-Files
> Graphics-Files-TIFF
> Graphics-Primitives
> Graphics-Text
> Kernel-Text
> Morphic-Basic
> Morphic-Events
> Morphic-Halos
> Morphic-Kernel
> Morphic-Layouts
> Morphic-Menus
> Morphic-Support
> Morphic-Tests
> Morphic-Text Support
> Morphic-Tools
> Morphic-Views for Models
> Morphic-Widgets
> Morphic-Worlds
> Shout-Parsing
> Shout-Styling
> UCompletion
> System-Exceptions Extensions
> System-Exceptions Kernel
> System-Files
> System-Object Storage
> System-Text
> System-TextAttributes
> Theme-Core
> Theme-Tests
> Theme-Themes
>
> 3. Other (Applications, Tools, System, Support, Tests): neither needed by Morphic nor STE
> Compiler-Tests
> GraphicsTests-Primitives
> Kernel-Tests
> KernelTests-Numbers
> KernelTests-Processes
> LinearAlgebra
> SUnit-UI
> Signal Processing
> Sound-Scores
> Sound-Synthesis
> System-Applications
> System-Archives
> System-Code Differ
> System-Compression
> System-Object Storage-Tests
> System-Support
> System-Tests
> Taskbar-Core
> Taskbar-Tests
> Tests-Exceptions
> Tests-Files
> Tools-Browser
> Tools-Changes
> Tools-Debugger
> Tools-Explorer
> Tools-File Contents Browser
> Tools-FileList
> Tools-Inspector
> Tools-Menus
> CollectionTests
> Tests-Bugs
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
>  

> Hello Bernhard and Juan
>
> I like this idea. And thank you for coming up with the three groups.
> Good to see what is compatible with Squeak and what is not.
>
> Two remarks come to my mind.
>
> a) What about loading _all_ classes of Cuis into a namespace of
> Squeak? And then gradually start relying on the Squeak classes?
>
>
> or alternatively
>
>
> b) There was an earlier attempt at loading 'SimpleMorphic' into Squeak
> which was only a partial success. It did not work reliably. So the
> question is not so much on the Cuis side but more on the receiving
> side.
>
>  

> A simple test could be to do a very minimal morphic (e.g. Morphic0)
> which basically just displays the desktop background (with a downsized
> version of PasteUpMorph) and with a mouse click does 'go to previous
> project'.
>
> The test in Squeak from the user point of view would be menu
> 'Projects' -> 'New Morphic0 project', then Morphic0 is entered and by
> a mouse click it would be left again.
>
> Then in batches more classes might be added from Cuis to go towards
> the full Cuis Morphic. So a second step might be a Worldmenu
> (Morphic02) and a third step an emergency exit to the Morphic of
> Squeak (Morphic03). A forth might be to be able to create
> RectangleMorphs and move them around (Morphic04) and so on. I.e. not a
> mechanic loading of the Cuis part but a batch-wise copy/paste and
> versioning exercise.
>
> To summarize point b)
> I think the fact that Squeak now has name spaces does not make a big
> difference in the difficulties which arise for the integration. The
> challenge is to find a good sequence of integration steps.
>
>
> Kind regards
> --Hannes
>
>  

> On 1/19/13, Bernhard Pieber <[hidden email]> wrote:
>  
>> Hi Juan,
>>
>> Now that Squeak supports Environments I thought a little bit what it would
>> take to load Cuis' Morphic and STE in Squeak. The minimum would be to define
>> three logical parts of Cuis:
>> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
>> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible
>> with Squeak
>> 3. Other (Applications, Tools, System, Support, Tests): neither needed by
>> Morphic nor STE
>>
>> If we had defined these, then we would need to "just" file out the Morphic
>> part and STE and file it in in a separate Squeak environment and do some
>> fairly minimal compatibility changes, right? ;-)
>>
>> Seriously, I looked briefly at the class categories and came up with first
>> rough separation. See below. Can you have a look? Do you see any obvious
>> errors? Any categories in Core which are not needed by Morphic? Any
>> categories in Core which are needed but are not reasonably compatible with
>> Squeak? Any categories in Morphic which are optional for STE? Any categories
>> in Other which are needed by Morphic or STE?
>>
>> Cheers,
>> Bernhard
>>
>> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
>> Balloon-Collections
>> Collections-Abstract
>> Collections-Arrayed
>> Collections-Sequenceable
>> Collections-SkipLists
>> Collections-Streams
>> Collections-Support
>> Collections-Unordered
>> Collections-Weak
>> Compiler-Exceptions
>> Compiler-Kernel
>> Compiler-ParseNodes
>> Compiler-Support
>> Compiler-Syntax
>> Kernel-Chronology
>> Kernel-Classes
>> Kernel-Magnitudes
>> Kernel-Methods
>> Kernel-Numbers
>> Kernel-Objects
>> Kernel-Processes
>> Network-Kernel
>> Package Support
>> SUnit
>> SUnit-Preload
>>
>> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible
>> with Squeak
>> Graphics-Display Objects
>> Graphics-Files
>> Graphics-Files-TIFF
>> Graphics-Primitives
>> Graphics-Text
>> Kernel-Text
>> Morphic-Basic
>> Morphic-Events
>> Morphic-Halos
>> Morphic-Kernel
>> Morphic-Layouts
>> Morphic-Menus
>> Morphic-Support
>> Morphic-Tests
>> Morphic-Text Support
>> Morphic-Tools
>> Morphic-Views for Models
>> Morphic-Widgets
>> Morphic-Worlds
>> Shout-Parsing
>> Shout-Styling
>> UCompletion
>> System-Exceptions Extensions
>> System-Exceptions Kernel
>> System-Files
>> System-Object Storage
>> System-Text
>> System-TextAttributes
>> Theme-Core
>> Theme-Tests
>> Theme-Themes
>>
>> 3. Other (Applications, Tools, System, Support, Tests): neither needed by
>> Morphic nor STE
>> Compiler-Tests
>> GraphicsTests-Primitives
>> Kernel-Tests
>> KernelTests-Numbers
>> KernelTests-Processes
>> LinearAlgebra
>> SUnit-UI
>> Signal Processing
>> Sound-Scores
>> Sound-Synthesis
>> System-Applications
>> System-Archives
>> System-Code Differ
>> System-Compression
>> System-Object Storage-Tests
>> System-Support
>> System-Tests
>> Taskbar-Core
>> Taskbar-Tests
>> Tests-Exceptions
>> Tests-Files
>> Tools-Browser
>> Tools-Changes
>> Tools-Debugger
>> Tools-Explorer
>> Tools-File Contents Browser
>> Tools-FileList
>> Tools-Inspector
>> Tools-Menus
>> CollectionTests
>> Tests-Bugs
>>
>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>    
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
>  

> H. Hirzel wrote:
>> Hello Bernhard and Juan
>>
>> I like this idea. And thank you for coming up with the three groups.
>> Good to see what is compatible with Squeak and what is not.
>>
>> Two remarks come to my mind.
>>
>> a) What about loading _all_ classes of Cuis into a namespace of
>> Squeak? And then gradually start relying on the Squeak classes?
>>
>>
>> or alternatively
>>
>>
>> b) There was an earlier attempt at loading 'SimpleMorphic' into Squeak
>> which was only a partial success. It did not work reliably. So the
>> question is not so much on the Cuis side but more on the receiving
>> side.
>>
>>
>
> I did a port of 'SimpleMorphic' for Pharo some time ago. It did work
> quite reliably. It was a technical success, but a social failure. No
> matter how much the Pharo folks talk about simplifying Morphic, you give
> it to them, and nobody adopts it.
>
>> A simple test could be to do a very minimal morphic (e.g. Morphic0)
>> which basically just displays the desktop background (with a downsized
>> version of PasteUpMorph) and with a mouse click does 'go to previous
>> project'.
>>
>> The test in Squeak from the user point of view would be menu
>> 'Projects' -> 'New Morphic0 project', then Morphic0 is entered and by
>> a mouse click it would be left again.
>>
>> Then in batches more classes might be added from Cuis to go towards
>> the full Cuis Morphic. So a second step might be a Worldmenu
>> (Morphic02) and a third step an emergency exit to the Morphic of
>> Squeak (Morphic03). A forth might be to be able to create
>> RectangleMorphs and move them around (Morphic04) and so on. I.e. not a
>> mechanic loading of the Cuis part but a batch-wise copy/paste and
>> versioning exercise.
>>
>> To summarize point b)
>> I think the fact that Squeak now has name spaces does not make a big
>> difference in the difficulties which arise for the integration. The
>> challenge is to find a good sequence of integration steps.
>>
>>
>> Kind regards
>> --Hannes
>>
>>
>
> The other challenge is to have enough time and energy to bring such
> project to usable state.

> Cheers,
> Juan Vuletich
>
>> On 1/19/13, Bernhard Pieber <[hidden email]> wrote:
>>
>>> Hi Juan,
>>>
>>> Now that Squeak supports Environments I thought a little bit what it
>>> would
>>> take to load Cuis' Morphic and STE in Squeak. The minimum would be to
>>> define
>>> three logical parts of Cuis:
>>> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
>>> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite
>>> incompatible
>>> with Squeak
>>> 3. Other (Applications, Tools, System, Support, Tests): neither needed
>>> by
>>> Morphic nor STE
>>>
>>> If we had defined these, then we would need to "just" file out the
>>> Morphic
>>> part and STE and file it in in a separate Squeak environment and do some
>>> fairly minimal compatibility changes, right? ;-)
>>>
>>> Seriously, I looked briefly at the class categories and came up with
>>> first
>>> rough separation. See below. Can you have a look? Do you see any obvious
>>> errors? Any categories in Core which are not needed by Morphic? Any
>>> categories in Core which are needed but are not reasonably compatible
>>> with
>>> Squeak? Any categories in Morphic which are optional for STE? Any
>>> categories
>>> in Other which are needed by Morphic or STE?
>>>
>>> Cheers,
>>> Bernhard
>>>
>>> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
>>> Balloon-Collections
>>> Collections-Abstract
>>> Collections-Arrayed
>>> Collections-Sequenceable
>>> Collections-SkipLists
>>> Collections-Streams
>>> Collections-Support
>>> Collections-Unordered
>>> Collections-Weak
>>> Compiler-Exceptions
>>> Compiler-Kernel
>>> Compiler-ParseNodes
>>> Compiler-Support
>>> Compiler-Syntax
>>> Kernel-Chronology
>>> Kernel-Classes
>>> Kernel-Magnitudes
>>> Kernel-Methods
>>> Kernel-Numbers
>>> Kernel-Objects
>>> Kernel-Processes
>>> Network-Kernel
>>> Package Support
>>> SUnit
>>> SUnit-Preload
>>>
>>> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite
>>> incompatible
>>> with Squeak
>>> Graphics-Display Objects
>>> Graphics-Files
>>> Graphics-Files-TIFF
>>> Graphics-Primitives
>>> Graphics-Text
>>> Kernel-Text
>>> Morphic-Basic
>>> Morphic-Events
>>> Morphic-Halos
>>> Morphic-Kernel
>>> Morphic-Layouts
>>> Morphic-Menus
>>> Morphic-Support
>>> Morphic-Tests
>>> Morphic-Text Support
>>> Morphic-Tools
>>> Morphic-Views for Models
>>> Morphic-Widgets
>>> Morphic-Worlds
>>> Shout-Parsing
>>> Shout-Styling
>>> UCompletion
>>> System-Exceptions Extensions
>>> System-Exceptions Kernel
>>> System-Files
>>> System-Object Storage
>>> System-Text
>>> System-TextAttributes
>>> Theme-Core
>>> Theme-Tests
>>> Theme-Themes
>>>
>>> 3. Other (Applications, Tools, System, Support, Tests): neither needed
>>> by
>>> Morphic nor STE
>>> Compiler-Tests
>>> GraphicsTests-Primitives
>>> Kernel-Tests
>>> KernelTests-Numbers
>>> KernelTests-Processes
>>> LinearAlgebra
>>> SUnit-UI
>>> Signal Processing
>>> Sound-Scores
>>> Sound-Synthesis
>>> System-Applications
>>> System-Archives
>>> System-Code Differ
>>> System-Compression
>>> System-Object Storage-Tests
>>> System-Support
>>> System-Tests
>>> Taskbar-Core
>>> Taskbar-Tests
>>> Tests-Exceptions
>>> Tests-Files
>>> Tools-Browser
>>> Tools-Changes
>>> Tools-Debugger
>>> Tools-Explorer
>>> Tools-File Contents Browser
>>> Tools-FileList
>>> Tools-Inspector
>>> Tools-Menus
>>> CollectionTests
>>> Tests-Bugs
>>>
>>>
>>> _______________________________________________
>>> Cuis mailing list
>>> [hidden email]
>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>>
>>>
>>
>> _______________________________________________
>> Cuis mailing list
>> [hidden email]
>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>>
>>
>>
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>

> H. Hirzel wrote:
> >Hello Bernhard and Juan
> >
> >I like this idea. And thank you for coming up with the three groups.
> >Good to see what is compatible with Squeak and what is not.
> >
> >Two remarks come to my mind.
> >
> >a) What about loading _all_ classes of Cuis into a namespace of
> >Squeak? And then gradually start relying on the Squeak classes?
> >
> >
> >or alternatively
> >
> >
> >b) There was an earlier attempt at loading 'SimpleMorphic' into Squeak
> >which was only a partial success. It did not work reliably. So the
> >question is not so much on the Cuis side but more on the receiving
> >side.
> >
> >  
>
> I did a port of 'SimpleMorphic' for Pharo some time ago. It did work
> quite reliably. It was a technical success, but a social failure. No
> matter how much the Pharo folks talk about simplifying Morphic, you give
> it to them, and nobody adopts it.

> Bernhard Pieber wrote:
>> Hi Juan,
>>
>> Now that Squeak supports Environments I thought a little bit what it would take to load Cuis' Morphic and STE in Squeak. The minimum would be to define three logical parts of Cuis:
>> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
>> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible with Squeak
>> 3. Other (Applications, Tools, System, Support, Tests): neither needed by Morphic nor STE
>>
>> If we had defined these, then we would need to "just" file out the Morphic part and STE and file it in in a separate Squeak environment and do some fairly minimal compatibility changes, right? ;-)
> You make it look quite easy. I wonder how easy it really is!
>
>> Seriously, I looked briefly at the class categories and came up with first rough separation. See below. Can you have a look? Do you see any obvious errors? Any categories in Core which are not needed by Morphic? Any categories in Core which are needed but are not reasonably compatible with Squeak? Any categories in Morphic which are optional for STE? Any categories in Other which are needed by Morphic or STE?
> It looks quite reasonable to me. Not sure if the utility of this work is enough to justify the effort, though.
>
> Cheers,
> Juan Vuletich

> On Mon, Jan 21, 2013 at 11:24:01PM -0300, Juan Vuletich wrote:
>> I did a port of 'SimpleMorphic' for Pharo some time ago. It did work
>> quite reliably. It was a technical success, but a social failure. No
>> matter how much the Pharo folks talk about simplifying Morphic, you give
>> it to them, and nobody adopts it.
>
> I did some work in Squeak to bring SimpleMorphic into Squeak as a kind
> of Squeak Project (MVC project, Morphic project, and SMxProject). This
> was intended as a proof of concept, and I never finished it. But clearly
> it is possible to do this. I do not yet know anything about Environments
> in Squeak, but it sounds to me like this might it easier to do.
>
> If I had unlimited time and energy (which I do not), here is how I would
> want to approach it from the Squeak side:
>
> 1) Fix enough of the bugs in MVC to make it useable. Mainly get the
> debugger working with ToolBuilder.
>
> 2) Unload Morphic from Squeak.
>
> 3) Load Cuis Morphic in Squeak and get it working.
>
> 4) Make some kind of Project (CuisMorphicProject?) for projects that use the
> Cuis Morphic.
>
> 5) Figure out how to use Environments so that Squeak Morphic and Cuis
> Morphic projects can exist in the same image, and make sure they are
> all reloadable.
>
> 6) Migrate Etoys to Cuis Morphic?
>
> Dave

> Cheers,
> Bernhard
>
> Am 22.01.2013 um 15:28 schrieb David T. Lewis:
> > On Mon, Jan 21, 2013 at 11:24:01PM -0300, Juan Vuletich wrote:
> >> I did a port of 'SimpleMorphic' for Pharo some time ago. It did work
> >> quite reliably. It was a technical success, but a social failure. No
> >> matter how much the Pharo folks talk about simplifying Morphic, you give
> >> it to them, and nobody adopts it.
> >
> > I did some work in Squeak to bring SimpleMorphic into Squeak as a kind
> > of Squeak Project (MVC project, Morphic project, and SMxProject). This
> > was intended as a proof of concept, and I never finished it. But clearly
> > it is possible to do this. I do not yet know anything about Environments
> > in Squeak, but it sounds to me like this might it easier to do.
> >
> > If I had unlimited time and energy (which I do not), here is how I would
> > want to approach it from the Squeak side:
> >
> > 1) Fix enough of the bugs in MVC to make it useable. Mainly get the
> > debugger working with ToolBuilder.
> >
> > 2) Unload Morphic from Squeak.
> >
> > 3) Load Cuis Morphic in Squeak and get it working.
> >
> > 4) Make some kind of Project (CuisMorphicProject?) for projects that use the
> > Cuis Morphic.
> >
> > 5) Figure out how to use Environments so that Squeak Morphic and Cuis
> > Morphic projects can exist in the same image, and make sure they are
> > all reloadable.
> >
> > 6) Migrate Etoys to Cuis Morphic?
> >
> > Dave
>
>
> _______________________________________________
> Cuis mailing list
> [hidden email]
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

>
> I did some work in Squeak to bring SimpleMorphic into Squeak as a kind
> of Squeak Project (MVC project, Morphic project, and SMxProject). This
> was intended as a proof of concept, and I never finished it. But clearly
> it is possible to do this. I do not yet know anything about Environments
> in Squeak, but it sounds to me like this might it easier to do.
>
> If I had unlimited time and energy (which I do not), here is how I would
> want to approach it from the Squeak side:
>
> 1) Fix enough of the bugs in MVC to make it useable. Mainly get the
> debugger working with ToolBuilder.
>
> 2) Unload Morphic from Squeak.
>
> 3) Load Cuis Morphic in Squeak and get it working.
>
> 4) Make some kind of Project (CuisMorphicProject?) for projects that use the
> Cuis Morphic.
>
> 5) Figure out how to use Environments so that Squeak Morphic and Cuis
> Morphic projects can exist in the same image, and make sure they are
> all reloadable.
>
> 6) Migrate Etoys to Cuis Morphic?
>
> Dave
>
>  

> Hi Juan,
>
> Here is a list of things to do to be able to load CuisMorphic in Squeak.
> In Cuis:
> 1. Allow the definition of "internal" Cuis packages. They are defined like external packages using PackageInfo. However, code in there is still maintained using ChangeSets, not pck.st files.
> 2. Allow the definition of Configurations. A configuration is a list of packages with a defined order which is used for loading and updating.
> 3. Define three Configurations, each corresponding to the parts defined below, by recategorizing extension methods to move them to the correct packages.
> 4. Export the CuisMorphic Configuration using Cuis-Cypress. Fix remaining bugs in Cuis-Cypress.
> 5. Fix world creation in Cuis.
>
> In Squeak:
> 5. Load CuisMorphic into a separate Environment. Fix remaining bugs in Environments.
> 6. Add a CuisMorphicProject as a holder for Cuis Morphs.
> 7. Add compatibility methods to Squeak to make CuisMorphic work.
>
> Optional:
> 8. Port MudPie to Cuis to help with 3.
> Did I forget anything? How much analysis would be needed to estimate the effort of those tasks.
>
>  

> Cheers,
> Bernhard
>
> Am 22.01.2013 um 03:20 schrieb Juan Vuletich:
>  
>> Bernhard Pieber wrote:
>>    
>>> Hi Juan,
>>>
>>> Now that Squeak supports Environments I thought a little bit what it would take to load Cuis' Morphic and STE in Squeak. The minimum would be to define three logical parts of Cuis:
>>> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
>>> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible with Squeak
>>> 3. Other (Applications, Tools, System, Support, Tests): neither needed by Morphic nor STE
>>>
>>> If we had defined these, then we would need to "just" file out the Morphic part and STE and file it in in a separate Squeak environment and do some fairly minimal compatibility changes, right? ;-)
>>>      
>> You make it look quite easy. I wonder how easy it really is!
>>
>>    
>>> Seriously, I looked briefly at the class categories and came up with first rough separation. See below. Can you have a look? Do you see any obvious errors? Any categories in Core which are not needed by Morphic? Any categories in Core which are needed but are not reasonably compatible with Squeak? Any categories in Morphic which are optional for STE? Any categories in Other which are needed by Morphic or STE?
>>>      
>> It looks quite reasonable to me. Not sure if the utility of this work is enough to justify the effort, though.
>>
>> Cheers,
>> Juan Vuletich
>>    
>
>