I just found this method. It contains this snippet:
Smalltalk isMorphic ifTrue: [ proj createViewIfAppropriate. ] ifFalse: [ ChangeSorter allChangeSets add: proj changeSet. ProjectView openAndEnter: proj. "Note: in MVC we get no further than the above" ].
Wouldn't that be better written by implementing
MVCProject >> #createViewIfAppropriate ChangeSorter allChangeSets add: proj changeSet. ProjectView openAndEnter: proj.
and ripping out the #isMorphic call?
frank
tell don't ask ;)
2013/6/3 Frank Shearar frank.shearar@gmail.com
I just found this method. It contains this snippet:
Smalltalk isMorphic ifTrue: [ proj createViewIfAppropriate. ] ifFalse: [ ChangeSorter allChangeSets add: proj changeSet. ProjectView openAndEnter: proj. "Note: in MVC we get no further than the above" ].
Wouldn't that be better written by implementing
MVCProject >> #createViewIfAppropriate ChangeSorter allChangeSets add: proj changeSet. ProjectView openAndEnter: proj.
and ripping out the #isMorphic call?
frank
Normally I would, but this is more complicated than a simple moving of a method. I don't know the how this method's used so I've assumed that proj is a Project-like thing, and there are no tests for this code (that I can see).
So I thought I'd ask before telling... this time :)
frank
On 03 Jun 2013, at 19:27, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
tell don't ask ;)
2013/6/3 Frank Shearar frank.shearar@gmail.com I just found this method. It contains this snippet:
Smalltalk isMorphic ifTrue: [ proj createViewIfAppropriate. ] ifFalse: [ ChangeSorter allChangeSets add: proj changeSet. ProjectView openAndEnter: proj. "Note: in MVC we get no further than the above" ].
Wouldn't that be better written by implementing
MVCProject >> #createViewIfAppropriate ChangeSorter allChangeSets add: proj changeSet. ProjectView openAndEnter: proj.
and ripping out the #isMorphic call?
frank
From the point of view of getting rid of #isMorphic, you are right that it
would be better to implement MVCProject>>createViewIfAppropriate, as well as this:
Project>>createViewIfAppropriate ^self subclassResponsibility
I'm not sure if the change carries its weight though. This does not seem like something that needs to be part of the Project API, and refactoring it may make it harder to understand what happens in #makeExistingView:project:projectsToBeDeleted: in the event that someone tries to use it in MVC.
This seems to be an Etoys method in which the #isMorphic test serves to document a bad thing that is going to happen if you were to use it in MVC (if you need to create the new view, you will enter that view and never execute the remainder of the method).
The call to #isMorphic may be bad but I think that adding unnecessary vocabulary to Project is undesirable, so in balance I would vote to not change the method.
I do suspect that a better refactoring is possible, but I don't know enough about how the project loading should work to suggest something.
Dave
On Mon, Jun 03, 2013 at 11:42:50PM +0100, Frank Shearar wrote:
Normally I would, but this is more complicated than a simple moving of a method. I don't know the how this method's used so I've assumed that proj is a Project-like thing, and there are no tests for this code (that I can see).
So I thought I'd ask before telling... this time :)
frank
On 03 Jun 2013, at 19:27, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
tell don't ask ;)
2013/6/3 Frank Shearar frank.shearar@gmail.com I just found this method. It contains this snippet:
Smalltalk isMorphic ifTrue: [ proj createViewIfAppropriate. ] ifFalse: [ ChangeSorter allChangeSets add: proj changeSet. ProjectView openAndEnter: proj. "Note: in MVC we get no further than the above" ].
Wouldn't that be better written by implementing
MVCProject >> #createViewIfAppropriate ChangeSorter allChangeSets add: proj changeSet. ProjectView openAndEnter: proj.
and ripping out the #isMorphic call?
frank
On 4 June 2013 00:52, David T. Lewis lewis@mail.msen.com wrote:
From the point of view of getting rid of #isMorphic, you are right that it
would be better to implement MVCProject>>createViewIfAppropriate, as well as this:
Project>>createViewIfAppropriate ^self subclassResponsibility
I'm not sure if the change carries its weight though. This does not seem like something that needs to be part of the Project API, and refactoring it may make it harder to understand what happens in #makeExistingView:project:projectsToBeDeleted: in the event that someone tries to use it in MVC.
This seems to be an Etoys method in which the #isMorphic test serves to document a bad thing that is going to happen if you were to use it in MVC (if you need to create the new view, you will enter that view and never execute the remainder of the method).
The call to #isMorphic may be bad but I think that adding unnecessary vocabulary to Project is undesirable, so in balance I would vote to not change the method.
I do suspect that a better refactoring is possible, but I don't know enough about how the project loading should work to suggest something.
Dang. I agree with you, and am keen to hear other proposals. I dislike the #isMorphic call, but mainly I'm trying to lose the ProjectView reference. This is one of, if I recall correctly, two references to the ST80 package in the base image.
frank
Dave
On Mon, Jun 03, 2013 at 11:42:50PM +0100, Frank Shearar wrote:
Normally I would, but this is more complicated than a simple moving of a method. I don't know the how this method's used so I've assumed that proj is a Project-like thing, and there are no tests for this code (that I can see).
So I thought I'd ask before telling... this time :)
frank
On 03 Jun 2013, at 19:27, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
tell don't ask ;)
2013/6/3 Frank Shearar frank.shearar@gmail.com I just found this method. It contains this snippet:
Smalltalk isMorphic ifTrue: [ proj createViewIfAppropriate. ] ifFalse: [ ChangeSorter allChangeSets add: proj changeSet. ProjectView openAndEnter: proj. "Note: in MVC we get no further than the above" ].
Wouldn't that be better written by implementing
MVCProject >> #createViewIfAppropriate ChangeSorter allChangeSets add: proj changeSet. ProjectView openAndEnter: proj.
and ripping out the #isMorphic call?
frank
On Tue, Jun 04, 2013 at 07:27:02AM +0100, Frank Shearar wrote:
On 4 June 2013 00:52, David T. Lewis lewis@mail.msen.com wrote:
From the point of view of getting rid of #isMorphic, you are right that it
would be better to implement MVCProject>>createViewIfAppropriate, as well as this:
Project>>createViewIfAppropriate ^self subclassResponsibility
I'm not sure if the change carries its weight though. This does not seem like something that needs to be part of the Project API, and refactoring it may make it harder to understand what happens in #makeExistingView:project:projectsToBeDeleted: in the event that someone tries to use it in MVC.
This seems to be an Etoys method in which the #isMorphic test serves to document a bad thing that is going to happen if you were to use it in MVC (if you need to create the new view, you will enter that view and never execute the remainder of the method).
The call to #isMorphic may be bad but I think that adding unnecessary vocabulary to Project is undesirable, so in balance I would vote to not change the method.
I do suspect that a better refactoring is possible, but I don't know enough about how the project loading should work to suggest something.
Dang. I agree with you, and am keen to hear other proposals. I dislike the #isMorphic call, but mainly I'm trying to lose the ProjectView reference. This is one of, if I recall correctly, two references to the ST80 package in the base image.
Ah yes, now I see the problem. You're right, this needs to be fixed. I think that Project>>openProject: does what we want here.
MVC is supposed to be completely unloadable/reloadable. What is the other reference to ST80 in the base image?
Dave
On 4 June 2013 12:05, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jun 04, 2013 at 07:27:02AM +0100, Frank Shearar wrote:
On 4 June 2013 00:52, David T. Lewis lewis@mail.msen.com wrote:
From the point of view of getting rid of #isMorphic, you are right that it
would be better to implement MVCProject>>createViewIfAppropriate, as well as this:
Project>>createViewIfAppropriate ^self subclassResponsibility
I'm not sure if the change carries its weight though. This does not seem like something that needs to be part of the Project API, and refactoring it may make it harder to understand what happens in #makeExistingView:project:projectsToBeDeleted: in the event that someone tries to use it in MVC.
This seems to be an Etoys method in which the #isMorphic test serves to document a bad thing that is going to happen if you were to use it in MVC (if you need to create the new view, you will enter that view and never execute the remainder of the method).
The call to #isMorphic may be bad but I think that adding unnecessary vocabulary to Project is undesirable, so in balance I would vote to not change the method.
I do suspect that a better refactoring is possible, but I don't know enough about how the project loading should work to suggest something.
Dang. I agree with you, and am keen to hear other proposals. I dislike the #isMorphic call, but mainly I'm trying to lose the ProjectView reference. This is one of, if I recall correctly, two references to the ST80 package in the base image.
Ah yes, now I see the problem. You're right, this needs to be fixed. I think that Project>>openProject: does what we want here.
MVC is supposed to be completely unloadable/reloadable. What is the other reference to ST80 in the base image?
Tools has extensions to ParagraphEditor, ScreenController and StringHolderView.
frank
Dave
On Tue, Jun 04, 2013 at 12:09:59PM +0100, Frank Shearar wrote:
On 4 June 2013 12:05, David T. Lewis lewis@mail.msen.com wrote:
MVC is supposed to be completely unloadable/reloadable. What is the other reference to ST80 in the base image?
Tools has extensions to ParagraphEditor, ScreenController and StringHolderView.
I don't see the dependencies ... what am I missing?
Dave
On 4 June 2013 13:06, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jun 04, 2013 at 12:09:59PM +0100, Frank Shearar wrote:
On 4 June 2013 12:05, David T. Lewis lewis@mail.msen.com wrote:
MVC is supposed to be completely unloadable/reloadable. What is the other reference to ST80 in the base image?
Tools has extensions to ParagraphEditor, ScreenController and StringHolderView.
I don't see the dependencies ... what am I missing?
The *Tools method categories cause a dependency from Tools -> ST80 because Tools requires those classes to exist.
You can track the dependencies through the DependencyBrowser in the Apps menu off TheWorldMainDockingBar.
frank
Dave
On Tue, Jun 04, 2013 at 01:20:36PM +0100, Frank Shearar wrote:
On 4 June 2013 13:06, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jun 04, 2013 at 12:09:59PM +0100, Frank Shearar wrote:
On 4 June 2013 12:05, David T. Lewis lewis@mail.msen.com wrote:
MVC is supposed to be completely unloadable/reloadable. What is the other reference to ST80 in the base image?
Tools has extensions to ParagraphEditor, ScreenController and StringHolderView.
I don't see the dependencies ... what am I missing?
The *Tools method categories cause a dependency from Tools -> ST80 because Tools requires those classes to exist.
You can track the dependencies through the DependencyBrowser in the Apps menu off TheWorldMainDockingBar.
Thanks!
Dave
On Tue, Jun 04, 2013 at 01:20:36PM +0100, Frank Shearar wrote:
On 4 June 2013 13:06, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jun 04, 2013 at 12:09:59PM +0100, Frank Shearar wrote:
On 4 June 2013 12:05, David T. Lewis lewis@mail.msen.com wrote:
MVC is supposed to be completely unloadable/reloadable. What is the other reference to ST80 in the base image?
Tools has extensions to ParagraphEditor, ScreenController and StringHolderView.
I don't see the dependencies ... what am I missing?
The *Tools method categories cause a dependency from Tools -> ST80 because Tools requires those classes to exist.
You can track the dependencies through the DependencyBrowser in the Apps menu off TheWorldMainDockingBar.
I don't think I trust what the DependencyBrowser is telling us here. The methods causing dependencies seem to be either methods that have matching implementations in both Morphic and MVC, or methods that are referenced from MVC menu picks. I don't think the dependencies are real.
So... I think that MVC remains safely unloadable and reloadable. The next challenge is to get to the point where we can say the same about Morphic :)
Dave
On 5 June 2013 00:02, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jun 04, 2013 at 01:20:36PM +0100, Frank Shearar wrote:
On 4 June 2013 13:06, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jun 04, 2013 at 12:09:59PM +0100, Frank Shearar wrote:
On 4 June 2013 12:05, David T. Lewis lewis@mail.msen.com wrote:
MVC is supposed to be completely unloadable/reloadable. What is the other reference to ST80 in the base image?
Tools has extensions to ParagraphEditor, ScreenController and StringHolderView.
I don't see the dependencies ... what am I missing?
The *Tools method categories cause a dependency from Tools -> ST80 because Tools requires those classes to exist.
You can track the dependencies through the DependencyBrowser in the Apps menu off TheWorldMainDockingBar.
I don't think I trust what the DependencyBrowser is telling us here. The methods causing dependencies seem to be either methods that have matching implementations in both Morphic and MVC, or methods that are referenced from MVC menu picks. I don't think the dependencies are real.
I disagree. Tools is extending classes in ST80. Were you to unload ST80, you would rip out part of Tools.
Or put it another way: take an image, unload ST80 and Tools, and then load Tools. I predict that loading Tools would fail, because it would say "I'm sorry Dave, I can't let you do that. I don't know about the classes ParagraphEditor, ScreenController and StringHolderView."
frank
So... I think that MVC remains safely unloadable and reloadable. The next challenge is to get to the point where we can say the same about Morphic :)
Dave
On Wed, Jun 05, 2013 at 07:44:15AM +0100, Frank Shearar wrote:
On 5 June 2013 00:02, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jun 04, 2013 at 01:20:36PM +0100, Frank Shearar wrote:
On 4 June 2013 13:06, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jun 04, 2013 at 12:09:59PM +0100, Frank Shearar wrote:
On 4 June 2013 12:05, David T. Lewis lewis@mail.msen.com wrote:
MVC is supposed to be completely unloadable/reloadable. What is the other reference to ST80 in the base image?
Tools has extensions to ParagraphEditor, ScreenController and StringHolderView.
I don't see the dependencies ... what am I missing?
The *Tools method categories cause a dependency from Tools -> ST80 because Tools requires those classes to exist.
You can track the dependencies through the DependencyBrowser in the Apps menu off TheWorldMainDockingBar.
I don't think I trust what the DependencyBrowser is telling us here. The methods causing dependencies seem to be either methods that have matching implementations in both Morphic and MVC, or methods that are referenced from MVC menu picks. I don't think the dependencies are real.
I disagree. Tools is extending classes in ST80. Were you to unload ST80, you would rip out part of Tools.
You would be removing the '*Tools' extensions in the ST80 package, but not anything that is directly part of the main 'Tools' package, right?
Or put it another way: take an image, unload ST80 and Tools, and then load Tools. I predict that loading Tools would fail, because it would say "I'm sorry Dave, I can't let you do that. I don't know about the classes ParagraphEditor, ScreenController and StringHolderView."
I understand what you mean now. Yes you are right. ST80 can be unloaded and reloaded, but there are methods categorized as '*Tools' in some ST80 classes, and presumably these would be a problem for loading Tools if those ST80 classes were not already present. Or maybe the Monticello loader knows how to handle this already?
I don't know if making a package like Tools fully independent of Morphic and ST80 is a practical goal. There are also extensive dependencies of Tools on Morphic. If the idea is to make Tools fully independent of the Morphic/MVC user interfaces, it looks to me like this would be a big challenge.
Dave
frank
So... I think that MVC remains safely unloadable and reloadable. The next challenge is to get to the point where we can say the same about Morphic :)
Dave
On 5 June 2013 13:20, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Jun 05, 2013 at 07:44:15AM +0100, Frank Shearar wrote:
On 5 June 2013 00:02, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jun 04, 2013 at 01:20:36PM +0100, Frank Shearar wrote:
On 4 June 2013 13:06, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jun 04, 2013 at 12:09:59PM +0100, Frank Shearar wrote:
On 4 June 2013 12:05, David T. Lewis lewis@mail.msen.com wrote: > > MVC is supposed to be completely unloadable/reloadable. What is the other > reference to ST80 in the base image?
Tools has extensions to ParagraphEditor, ScreenController and StringHolderView.
I don't see the dependencies ... what am I missing?
The *Tools method categories cause a dependency from Tools -> ST80 because Tools requires those classes to exist.
You can track the dependencies through the DependencyBrowser in the Apps menu off TheWorldMainDockingBar.
I don't think I trust what the DependencyBrowser is telling us here. The methods causing dependencies seem to be either methods that have matching implementations in both Morphic and MVC, or methods that are referenced from MVC menu picks. I don't think the dependencies are real.
I disagree. Tools is extending classes in ST80. Were you to unload ST80, you would rip out part of Tools.
You would be removing the '*Tools' extensions in the ST80 package, but not anything that is directly part of the main 'Tools' package, right?
Yes. Tools would still work, providing Monticello didn't barf on loading.
Or put it another way: take an image, unload ST80 and Tools, and then load Tools. I predict that loading Tools would fail, because it would say "I'm sorry Dave, I can't let you do that. I don't know about the classes ParagraphEditor, ScreenController and StringHolderView."
I understand what you mean now. Yes you are right. ST80 can be unloaded and reloaded, but there are methods categorized as '*Tools' in some ST80 classes, and presumably these would be a problem for loading Tools if those ST80 classes were not already present. Or maybe the Monticello loader knows how to handle this already?
I don't know. I'd run a test, but I'm running at capacity at the moment.
I don't know if making a package like Tools fully independent of Morphic and ST80 is a practical goal. There are also extensive dependencies of Tools on Morphic. If the idea is to make Tools fully independent of the Morphic/MVC user interfaces, it looks to me like this would be a big challenge.
I think it should be. Specifically, Tools should only depend on ToolBuilder-Kernel. Most (but by no means all) of those Morphic dependencies stem from FileList2. I've asked about this class before, and I only got one reply: Stéphane Rollandin says that he subclasses it in muO, but that "I don't think it will be a huge problem for me if you nuke it though so AFAIC do as you want." Losing FileList2 would also remove the Tools -> MorphicExtras dependency, for extra good.
Actually, I'd phrase that even stronger: I don't think _anything_ (except maybe Etoys, but that's a special case) should have a dependency on Morphic or ST80, except as mediated through ToolBuilder-Kernel. That would make the rest of the image UI agnostic, which is a fine place to be!
frank
Dave
frank
So... I think that MVC remains safely unloadable and reloadable. The next challenge is to get to the point where we can say the same about Morphic :)
Dave
On 5 June 2013 13:35, Frank Shearar frank.shearar@gmail.com wrote:
On 5 June 2013 13:20, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Jun 05, 2013 at 07:44:15AM +0100, Frank Shearar wrote:
On 5 June 2013 00:02, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jun 04, 2013 at 01:20:36PM +0100, Frank Shearar wrote:
On 4 June 2013 13:06, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jun 04, 2013 at 12:09:59PM +0100, Frank Shearar wrote: > On 4 June 2013 12:05, David T. Lewis lewis@mail.msen.com wrote: > > > > MVC is supposed to be completely unloadable/reloadable. What is the other > > reference to ST80 in the base image? > > Tools has extensions to ParagraphEditor, ScreenController and StringHolderView. >
I don't see the dependencies ... what am I missing?
The *Tools method categories cause a dependency from Tools -> ST80 because Tools requires those classes to exist.
You can track the dependencies through the DependencyBrowser in the Apps menu off TheWorldMainDockingBar.
I don't think I trust what the DependencyBrowser is telling us here. The methods causing dependencies seem to be either methods that have matching implementations in both Morphic and MVC, or methods that are referenced from MVC menu picks. I don't think the dependencies are real.
I disagree. Tools is extending classes in ST80. Were you to unload ST80, you would rip out part of Tools.
You would be removing the '*Tools' extensions in the ST80 package, but not anything that is directly part of the main 'Tools' package, right?
Yes. Tools would still work, providing Monticello didn't barf on loading.
Or put it another way: take an image, unload ST80 and Tools, and then load Tools. I predict that loading Tools would fail, because it would say "I'm sorry Dave, I can't let you do that. I don't know about the classes ParagraphEditor, ScreenController and StringHolderView."
I understand what you mean now. Yes you are right. ST80 can be unloaded and reloaded, but there are methods categorized as '*Tools' in some ST80 classes, and presumably these would be a problem for loading Tools if those ST80 classes were not already present. Or maybe the Monticello loader knows how to handle this already?
I don't know. I'd run a test, but I'm running at capacity at the moment.
I don't know if making a package like Tools fully independent of Morphic and ST80 is a practical goal. There are also extensive dependencies of Tools on Morphic. If the idea is to make Tools fully independent of the Morphic/MVC user interfaces, it looks to me like this would be a big challenge.
I think it should be. Specifically, Tools should only depend on ToolBuilder-Kernel.
One way to break this Tools->ST80 dependency is adding a new package, ST80Tools. This would contain the ST80 specific extensions. It makes things slightly more complicated for loading/unloading MVC, in that "unload" would mean "unload ST80 and any of its associated packages (currently just ST80Tools)", and similarly for loading.
frank
Most (but by no means all) of those Morphic dependencies stem from FileList2. I've asked about this class before, and I only got one reply: Stéphane Rollandin says that he subclasses it in muO, but that "I don't think it will be a huge problem for me if you nuke it though so AFAIC do as you want." Losing FileList2 would also remove the Tools -> MorphicExtras dependency, for extra good.
Actually, I'd phrase that even stronger: I don't think _anything_ (except maybe Etoys, but that's a special case) should have a dependency on Morphic or ST80, except as mediated through ToolBuilder-Kernel. That would make the rest of the image UI agnostic, which is a fine place to be!
frank
Dave
frank
So... I think that MVC remains safely unloadable and reloadable. The next challenge is to get to the point where we can say the same about Morphic :)
Dave
On Sun, Jun 30, 2013 at 11:42:01AM +0100, Frank Shearar wrote:
On 5 June 2013 13:35, Frank Shearar frank.shearar@gmail.com wrote:
On 5 June 2013 13:20, David T. Lewis lewis@mail.msen.com wrote:
I don't know if making a package like Tools fully independent of Morphic and ST80 is a practical goal. There are also extensive dependencies of Tools on Morphic. If the idea is to make Tools fully independent of the Morphic/MVC user interfaces, it looks to me like this would be a big challenge.
I think it should be. Specifically, Tools should only depend on ToolBuilder-Kernel.
One way to break this Tools->ST80 dependency is adding a new package, ST80Tools. This would contain the ST80 specific extensions. It makes things slightly more complicated for loading/unloading MVC, in that "unload" would mean "unload ST80 and any of its associated packages (currently just ST80Tools)", and similarly for loading.
frank
That seems like a reasonable approach. I think it would be important to take the same approach for both MVC and Morphic, so we could eventually have for MVC:
ST80-Controllers \ ST80-Editors \ ... > - current ST80 package ST80-Views / ST80-ToolBuilder / ST80Tools - new ST80Tools package
And for Morphic:
Morphic-Balloon \ Morphic-Basic \ ... > - current Morphic package Morphic-Worlds / Morphic-ToolBuilder / MorphicTests - current MorphicTests package MorphicTools - new MorphicTools package
Is that right?
Dave
p.s. I've been trying for a *long* time to get the debugger working in MVC again. I think I almost have it working now, and hope to be able to submit some fixes before too much more time goes by. It turns out to be rather tricky to debug the control loop in MVC, and fixing the debugger without the assistance of a debugger has proven something of a challenge as well.
On 30 June 2013 14:03, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Jun 30, 2013 at 11:42:01AM +0100, Frank Shearar wrote:
On 5 June 2013 13:35, Frank Shearar frank.shearar@gmail.com wrote:
On 5 June 2013 13:20, David T. Lewis lewis@mail.msen.com wrote:
I don't know if making a package like Tools fully independent of Morphic and ST80 is a practical goal. There are also extensive dependencies of Tools on Morphic. If the idea is to make Tools fully independent of the Morphic/MVC user interfaces, it looks to me like this would be a big challenge.
I think it should be. Specifically, Tools should only depend on ToolBuilder-Kernel.
One way to break this Tools->ST80 dependency is adding a new package, ST80Tools. This would contain the ST80 specific extensions. It makes things slightly more complicated for loading/unloading MVC, in that "unload" would mean "unload ST80 and any of its associated packages (currently just ST80Tools)", and similarly for loading.
frank
That seems like a reasonable approach. I think it would be important to take the same approach for both MVC and Morphic, so we could eventually have for MVC:
ST80-Controllers \ ST80-Editors \ ... > - current ST80 package ST80-Views / ST80-ToolBuilder / ST80Tools - new ST80Tools package
And for Morphic:
Morphic-Balloon \ Morphic-Basic \ ... > - current Morphic package Morphic-Worlds / Morphic-ToolBuilder / MorphicTests - current MorphicTests package MorphicTools - new MorphicTools package
Is that right?
Yes, that's exactly right. We don't have a MorphicTools only because we haven't needed one - Tools has no extensions to Morphic classes.
frank
Dave
p.s. I've been trying for a *long* time to get the debugger working in MVC again. I think I almost have it working now, and hope to be able to submit some fixes before too much more time goes by. It turns out to be rather tricky to debug the control loop in MVC, and fixing the debugger without the assistance of a debugger has proven something of a challenge as well.
squeak-dev@lists.squeakfoundation.org
-
David T. Lewis -
Frank Shearar -
Nicolas Cellier