On 31 January 2011 08:21, Stéphane Ducasse <[email protected]> wrote: >> >> The answer of 'Smalltalk tools' should be a tool registry instance. >> >> The tool registry is a system-wide object where packages can register >> their tools. >> I don't remember all of the details, but the idea, when i implemented >> it was following: >> >> - you registering your tool(s) by sending: >> >> Smalltalk tools addTool: myTool verb: #myTool > > would be good to have > addTool: myTool named: #myTool kind: #codebrowser > > so that we can avoid to have one subclass per kind. >
can you elaborate a bit? i mean why you need to have two different keys for one tool? When you registering browser at #browser, then in this way everyone refer to it using 'Smalltalk tools browser' , and of course they expecting that given tool supports certain browser protocol, which means its already of kind of 'codebrowser'.. For cases, when you have multiple browsers installed and need to show user a choice which one to use (like standard browser vs OB one) this can be solved differently: Smalltalk tools addEntry: #availableBrowsers value: WeakSet new. Smalltalk tools availableBrowsers add: MyBrowserClass. Smalltalk tools availableBrowsers add: MyOtherBrowserClass. so, then you can enumerate available browsers by using: Smalltalk tools availableBrowsers. > Stef > > -- Best regards, Igor Stasenko AKA sig.
