Issue
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 |
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 16:21, Henrik Johansen <[hidden email]> 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 |
In reply to this post by Nicolai Hess
Yes, we should add that… this way people can change the tools easily. We can then later improve the implementation… Marcus
|
In reply to this post by Marcus Denker-4
Yes
less is more ;) Le 29/12/14 12:20, Marcus Denker a écrit : >> On 19 Dec 2014, at 16:21, Henrik Johansen <[hidden email]> 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 > > > |
Free forum by Nabble | Edit this page |