> On 19 Dec 2014, at 16:21, Henrik Johansen <[email protected]>
> wrote:
>
> 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.
>
In retrospect, maybe I should have unified towards the AppRegistry… but on the
other hand, the good thing is that we now have *one* mechanism, not 2-and-a-half
mixed like it used to be. This means we can replace/enhance it as needed…
Marcus
