ToolRegistry need to support multiple registrations per tool
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
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 <nicolaihess@web.de> 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
On 19 Dec 2014, at 16:21, Henrik Johansen <henrik.s.johansen@veloxit.no> 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
Yes less is more ;) Le 29/12/14 12:20, Marcus Denker a écrit :
On 19 Dec 2014, at 16:21, Henrik Johansen <henrik.s.johansen@veloxit.no> 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
On 19 Dec 2014, at 14:08, Nicolai Hess <nicolaihess@web.de> 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?
Yes, we should add that⦠this way people can change the tools easily. We can then later improve the implementation⦠Marcus
participants (4)
-
Henrik Johansen -
Marcus Denker -
Nicolai Hess -
stepharo