Kill tools registry in Smalltalk

[hernanmd]

The Tool Registry has shortcuts to multiple common tools in the system, such as:

Smalltalk tools browser.
Smalltalk tools workspace.
Smalltalk tools fileList.

However, a shortcut to access the debugger is missing:

Smalltalk tools debugger

This is easy to add and will make accessing the debugger more consistent with other tools.

[guillep]

Ping @Ducasse , maybe you should sync because we should stop using Smalltalk, and thus that registry :)

[jecisc]

A first step could be to add a tool registry to the spec application and make sure the pharo application returns this Smalltalk tools instance

[Ducasse]

@hernanmd Hi hernan Smallltalk tools should be killed. We should not use a global variable. Instead StApplication should be responsible for it (if it does not have it we should introduce it).

[StevenCostiou]

In fact we removed Smalltalk tools debugger because it made debugger access totally inconsistent, as there were many debuggers and some of them could, if accessed through this global, actually decide to open other debuggers that were not the one returned by this global.

The other three should be killed, and instead the logic of deciding which one is the default tool should be the responsibility of the tool infrastructure.

[Ducasse]

Totally in sync with you :)

[hernanmd]

I see multiple options then to access tools:

This one used by IceTipModel, RBInteractionDriver and StPresenter.

StPharoApplication current

StPharoApplication inherits from SpApplication, so it depends of Spec.

This one accessing through Presenter used only in IceTipPresenter:

StPresenter currentApplication. "a StPharoApplication"

This one which for which we should introduce the new class to hold the registry:

StApplication

Which one do you prefer?

[Ducasse]

For RB I will do it.

[Ducasse]

You should ask esteban. In a presenter I always do self application

[hernanmd]

So @estebanlm do you think the tool registry should depend on Spec? If not I will introduce StApplication

[estebanlm]

There is already a StPharoApplication, why you need a StApplication ?

[hernanmd]

We're just discussing here if we should have a tool registry which depends of Spec. As I commented above, StPharoApplication means tool registry will have a Spec dependency.

So a tool registry should depend on Spec?

[estebanlm]

So @estebanlm do you think the tool registry should depend on Spec? If not I will introduce StApplication

And no, it should not depend on spec, it should depend on newtools which is an application of spec.

[estebanlm]

We're just discussing here if we should have a tool registry which depends of Spec. As I commented above, StPharoApplication means tool registry will have a Spec dependency.

So a tool registry should depend on Spec?

nope. StPharoApplication is an application of spec. Not spec itself.

[estebanlm]

if you see StPharoApplication, there is already a method called tools that delegates to Smalltalk tools.
The idea was eventually inverse that relation because the tools are GUI tools, hence part of the IDE, hence part of StPharoApplication

but still newtools ~= spec. So, the new tools will have a tool registry, which is a correct approach. Spec itself will not have a dependency.