2008/11/9 Stéphane Ducasse <stephane.ducasse@inria.fr>:

I can tell you that removing etoy is really really boring/difficult/ even if you think that this is **just** removing some methods. I really hope that I will not break too much but really this is a so huge mess.

I'm appreciate your efforts. Keep going! Just one question. You seem planning to remove Project from system, as part of Etoys. I'm not really sure about it. A removal of Projects will lead to model, which having only a single World (a PasteUpMorph instance), what i fear of, because i want to make a plugin which supports multiple windows, and therefore each window can have own PasteUpMorph instance. And it seems like its least painful way to get multiple windows support. Of course, it would require rethinking the role of Display & World globals, because there will be more than a single window and this will require to do something with code, which assuming that there is always a Display/World where everyone can put his dirty hands on :) For instance, i have no idea, what to do with commonly used (and quite convenient, in fact) message , like #openInWorld. When you have multiple worlds, its a big question, where new morph should appear. Maybe, as solution, a World/Display globals can stay, but they will track the currently active window. In this way, all new morphs will appear in currently active window. The problem is, that its not really necessary for window to be associated with PasteUpMorph - it can be a window which only having a Form for drawing and nothing more, or window which may use different UI framework and therefore creating/keeping an instance of PasteUpMorph for it is not an option. -- Best regards, Igor Stasenko AKA sig.

2008/11/9 Stéphane Ducasse <stephane.ducasse@inria.fr>:

...

I'm appreciate your efforts. Keep going!

Just one question. You seem planning to remove Project from system, as part of Etoys. I'm not really sure about it. A removal of Projects will lead to model, which having only a single World (a PasteUpMorph instance), what i fear of, because i want to make a plugin which supports multiple windows, and therefore each window can have own PasteUpMorph instance.

I do not know. now each time I look at Project and its impact everywhere. May be it would be better to reimplement a clean multiple world abstraction. For now I'm removing player and etoy support from Project when I see them.

...

And it seems like its least painful way to get multiple windows support.

Of course, it would require rethinking the role of Display & World globals, because there will be more than a single window and this will require to do something with code, which assuming that there is always a Display/World where everyone can put his dirty hands on :) For instance, i have no idea, what to do with commonly used (and quite convenient, in fact) message , like #openInWorld. When you have multiple worlds, its a big question, where new morph should appear.

Maybe, as solution, a World/Display globals can stay, but they will track the currently active window. In this way, all new morphs will appear in currently active window. The problem is, that its not really necessary for window to be associated with PasteUpMorph - it can be a window which only having a Form for drawing and nothing more, or window which may use different UI framework and therefore creating/keeping an instance of PasteUpMorph for it is not an option.

Probably but I do not really know. Now I'm trying not to break Morphic while removing etoys. I think that once this is done we will have to think about it. May be rebuilding another solution on the side and switching is the best when I see the current state of the code. Not a really optimistic answer but I'm getting burned by etoy

Right, i dealt with Morphic code a bit, when implemented a GLCanvas thingy, and know how awfull it can be :) I think, that inherent basic structure of implementation, like SystemDictionary and its globals and lack of modular design at first place, makes developers tend to write highly wired-up code, which is then hard to decompose. To my sense, lack of modularity is the main drawback of smalltalk-80 implementation. And the main reason, why smalltalk is not the #1 language in the world.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

I'm sure I missed a lot. As you say, the tendrils go deep! Regards, Gary. ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> Sent: Saturday, November 08, 2008 9:04 PM Subject: [Pharo-project] About etoy cleaning

Hi guys

I just wanted to let you know that I'm working on etoy cleaning from Object, Morph and friends. And I will probably do some mistakes (because this is complex). I'm trying to do that concentrated but still this is serious beast.

Now I'm keeping a list of my progress at this page http://code.google.com/p/pharo/w/edit/CurrentlyWorkingOn so that you can follow my progression and that I'm not lost either.

I'm using gary etoy removal and going over his list and checking senders of senders .... and verifying when I have doubts. and I'm finding missed points from time to time and this is normal when we see the complexity of etoy and morphic together. So gary may be at the end I would appreciate that you have a look at the stuff I'm removing. May be by doing a "changes" comparison. Right now I'm cleaning object and I will keep a list of the difficult methods I did not fixed yet. May be these ones will be easier to treat when etoy will be removed. Stef

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project