There used to be a class called AppRegistry in Pharo, which was nothing more than a selection in a list, with an API's for adding/removing options and changing the current selection. (only through popups, but that could easily be extended to provide settings entries). The code might've needed a bit of cleanup (making collection of available options weak, for example), but the concept was sound.
IMHO, rather than the delegation through ToolRegistry, it would've been nice to have built upon AppRegistry and have Inspector/Browser/Debugger as subclasses of that. Then you'd still maintain indirection of which ToolX are available / currently in use, and code would be nice and understandable like: ToolX open instead of ToolRegistry openToolX. When new tools classifications are added, you'd also avoid progressively extending ToolRegistry into a behemoth of #openToolX etc. methods (ref. UIManager). Sadly, SoundService was the only real App classification in use, and the code seems to have been removed in 4.0. Cheers, Henry > On 19 Dec 2014, at 2:08 , Nicolai Hess <[email protected]> wrote: > > Issue > 10529 <https://pharo.fogbugz.com/default.asp?10529> > ToolRegistry need to support multiple registrations per tool > > My solution : > A ToolRegistry subclass (PharoCommonTools) that memorized all registered > tools. > And, for some common tools, like browser, debugger, inspector, workspace, > it provides settings entry to reset the registration to a prior tool. > > What do you think? > > (maybe a subclass of ToolRegistry isn't need and we can merge this. > And I don't like to "hardcode" the tools support for inspector, debugger, > ..., > but I don't know how we can add the settings interface without proper names, > maybe someone knows a more "generic" way to add the settings for every > key that is/was used for a tool registration ) > > > nicolai > > >
