On 03.12.2008, at 15:33, Torsten Bergmann wrote:

It's not a question of compatibility, the question is where will Polymorph be continued - in SqS/Pharo or SqS/UIEnhancements or both?

I didnt notice (until now) that the integrated plymorph packages are now also in the SqS/Pharo repository.

A new branch or just a move? Same question applies for other packages integrated later.

The problem is that removing etoys is not a clean thing. We have first methods that are needed to be changed for both removing etoys *and* polymorph. So that's why the packages need to be in the pharo repository. In general, if you think about code quality or modularity in the context of Squeak: Think about the worst you can think of, then multiply it by a factor of 100. Then you get to what the current state is in Squeak. It's a mess of epic proportions...

Bye Torsten

BTW: Will I have to open an issue when I just put something into the inbox (like a new ScriptLoader from today that fixes Seaside loading)?

Yes. The bug-tracker is like a TODO list. Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker

On 03.12.2008, at 15:49, Gary Chambers wrote:

Well, I will try to maintain things such that Polymorph is compatible with both for now (an extra package for Squeak). If Markus can let me know the differences I'll move the affected methods out.

1) FileList2 is gone. the method #morphicPatternPane is now in FileList 2) Morph>>#privateMoveBy: Here we removed all the code at the beginning related to Pen: extension ifNotNil: [extension player ifNotNil: ["Most cases eliminated fast by above test" self getPenDown ifTrue: ["If this is a costume for a player with its pen down, draw a line." self moveWithPenDownBy: delta]]]. That's it for now... in addition, the polymorph overrides did override some change of the etoy and preference cleanups. e.g. Debugger>>buildMorphicNotifierLabelled: label message: messageString has now again a check for "Preferences eToyFriendly". I am sure there are some more of these case. Marcus

As for the PasswordDialogWindow... just putting in now. Reworked to be more in keeping with Polymorph.

Regards, Gary.

----- Original Message ----- From: "Torsten Bergmann" <astares@gmx.de> To: <pharo-project@lists.gforge.inria.fr> Sent: Wednesday, December 03, 2008 2:33 PM Subject: [Pharo-project] Polymorph password dialog enhancement

...

It's not a question of compatibility, the question is where will Polymorph be continued - in SqS/Pharo or SqS/UIEnhancements or both?

I didnt notice (until now) that the integrated plymorph packages are now also in the SqS/Pharo repository.

A new branch or just a move? Same question applies for other packages integrated later.

Bye Torsten

BTW: Will I have to open an issue when I just put something into the inbox (like a new ScriptLoader from today that fixes Seaside loading)?

-- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

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

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

-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker

On 03.12.2008, at 22:10, Stéphane Ducasse wrote:

...

The problem is that removing etoys is not a clean thing. We have first methods that are needed to be changed for both removing etoys *and* polymorph. So that's why the packages need to be in the pharo repository.

In general, if you think about code quality or modularity in the context of Squeak: Think about the worst you can think of, then multiply it by a factor of 100. Then you get to what the current state is in Squeak. It's a mess of epic proportions...

Not that quite :) :-)

It is getting better every day. :) And I will really get better. Now this is true that etoy is a great idea

Yes!

with a bad implementation.

Maybe it's not even the implementation... every implementation has it's problems. I think in hindsight, the problem is that they just never cleaned up. And with that, they just stopped to invest in the future. It was always "the two week prototype that will be replaced soon". And 10 years later, it was a mess (and there was no replacement, of course). There is a lot that one can learn from that. (And I hope that viewpoints did a good postmortem analysis of the etoys project so that they can incorporate these lessons into the things that they are working on right now...) Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker