ToolRegistry need to support multiple registrations per tool

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

ToolRegistry need to support multiple registrations per tool

Nicolai Hess
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



Reply | Threaded
Open this post in threaded view
|

Re: ToolRegistry need to support multiple registrations per tool

Henrik Sperre Johansen
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 <[hidden email]> wrote:

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




Reply | Threaded
Open this post in threaded view
|

Re: ToolRegistry need to support multiple registrations per tool

Marcus Denker-4

> 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


Reply | Threaded
Open this post in threaded view
|

Re: ToolRegistry need to support multiple registrations per tool

Marcus Denker-4
In reply to this post by Nicolai Hess

On 19 Dec 2014, at 14:08, Nicolai Hess <[hidden email]> wrote:

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?


Yes, we should add that… this way people can change the tools easily.
We can then later improve the implementation…

Marcus
Reply | Threaded
Open this post in threaded view
|

Re: ToolRegistry need to support multiple registrations per tool

stepharo
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
>
>
>