[*1] Try browsing the sender of some message or a class - you will very quickly notice why I don't like the usage of "AppRegistry default" since it raises completely needless errors when for example trying to browse a class -- compare this with the notifier you get when trying to browse a selector which uses ToolSet's interpretation of "proper" AppRegistry behavior.
So we will have to fix that.
Actually, the above note related to a message that I sent to Squeak-dev about the general use of AppRegistry but it seems like the list is dead for now. I'm attaching it for reference.
http://www.impara.de/~andreas/iSqueak/3.8/PlusTools-ar.16.mcz [300k]
Ok so you already did it ;). So I would suggest that we only use this one. :)
Well, there are a few things missing and originally I needed the PlusTools to figure out how to go about unloading and dealing with the regular tools. The PlusTools *definitely* need some more work, what I've done covers the basics but there are plenty of things that still need to be fixed.
I thought that there was a version of MC UI was relying on ToolBuilder.
Yes, there is. I'm planning to use it for Tweak.
- Refactoring of ChangeSet and ChangeSorter - all of the actual
I do not have the time right now to look at it but did you change the notification mechanism? I'm curious to see how the decoupling offered by the notification mechanism helps.
I simply separated the functionality of dealing with changes from the user interface (ChangeSorter). Mostly it meant moving class methods from ChangeSorter to ChangeSet and then fix patterns like "ChangeSorter changeSetNamed: ..." to use "ChangeSet named: ...".
Cheers, - Andreas