feat(toolbox): Refactor Toolbox State Management and fix it

[sedghi]

Issues

• The toolbox's active state is now determined by the click, and nothing is displayed until an icon is clicked (see test case 1 below).
• We've removed the separate context for the toolbox option state, as the ToolbarService can manage all states itself.

Changes:

• The ToolboxContext and provider have been removed.
• Toolbar state is now exclusively managed within the Toolbarservice.
• Option state is also managed within the Toolbarservice.
• Instead of having an active tool per toolbox, it's now derived from evaluators.
• Flat definition of tool buttons

Test with this

1. Go to segmentation mode
2. add shapes to the main toolbar

toolbarService.createButtonSection('primary', [
  'Shapes',
  'WindowLevel',
  'Pan',
  'Zoom',
  'TrackballRotate',
  'Capture',
  'Layout',
  'Crosshairs',
  'MoreTools',
]);

toolbarService.createButtonSection('segmentationToolbox', ['BrushTools', 'Shapes']);

Cannot Show tool options

Before

CleanShot.2025-03-03.at.23.07.40.mp4

After

CleanShot.2025-03-03.at.23.14.42.mp4

---

Cannot hydrate active tool options

Before

CleanShot.2025-03-03.at.23.16.02.mp4

After

CleanShot.2025-03-03.at.23.16.35.mp4

---

Unlock advanced tool options placement anywhere in the UI

example:

Enable Action and Other Types of Buttons Inside the Toolbox

Previously, clicking an icon would activate it. Now, certain icons (like interpolation or segment bidirectional) should only trigger an action.

---

Migration Guides

ToolBox

Previously, the segmentation toolbox was not using an evaluator property. This is now taken into account

evaluators in Toolbox

// old
{
  id: 'BrushTools',
  uiType: 'ohif.buttonGroup',
  props: {
    groupId: 'BrushTools',
  }
}

// now
{
  id: 'BrushTools',
  uiType: 'ohif.buttonGroup',
  props: {
    groupId: 'BrushTools',
    evaluate: 'evaluate.cornerstone.hasSegmentation',
  }
}

Replace Toolbox imports from ui-next with extension-default

- import { Toolbox } from '@ohif/ui-next';
+ import { Toolbox } from '@ohif/extension-default';

Ensure you're importing the Toolbox component from the correct location:

// New import pattern
import { Toolbox } from '@ohif/extension-default';

// Usage remains similar
<Toolbox
  servicesManager={servicesManager}
  buttonSectionId="segmentation"
  title="Segmentation Tools"
/>

Remove ToolboxProvider from composition root

If you have the ToolboxProvider in your application composition, remove it:

// In App.tsx or similar
const appComposition = [
  [ThemeWrapperNext],
  [ThemeWrapper],
  [SystemContextProvider, { commandsManager, extensionManager, hotkeysManager, servicesManager }],
- [ToolboxProvider],
  [ViewportGridProvider, { service: viewportGridService }],
  // Other providers...
];

we now keep the state for toolbar inside the ToolbarService itself

3. Update tool option handlers to use onChange instead of commands

- <RowSegmentedControl
-   key={option.id}
-   option={option}
- />

+ <RowSegmentedControl
+   key={option.id}
+   option={option}
+   onChange={option.onChange}
+ />

Tool Definitions: Moving to Section-Based Definitions

This migration represents a significant step toward a more extension-based toolbar system. We've moved away from the nested primary/items structure in favor of a flatter, more composable section-based approach.

Deprecated: Nested Toolbar Structures

- {
-   id: 'MeasurementTools',
-   uiType: 'ohif.toolButtonList',
-   props: {
-     groupId: 'MeasurementTools',
-     evaluate: 'evaluate.group.promoteToPrimaryIfCornerstoneToolNotActiveInTheList',
-     primary: createButton({
-       id: 'Length',
-       icon: 'tool-length',
-       label: 'Length',
-       tooltip: 'Length Tool',
-       commands: setToolActiveToolbar,
-       evaluate: 'evaluate.cornerstoneTool',
-     }),
-     secondary: {
-       icon: 'chevron-down',
-       tooltip: 'More Measure Tools',
-     },
-     items: [
-       createButton({ ... }),
-       createButton({ ... }),
-       // More nested buttons
-     ],
-   },
- }

New Approach: Section-Based Definitions

+ // 1. Define the toolbar section container
+ {
+   id: 'MeasurementTools',
+   uiType: 'ohif.toolButtonList',
+   props: {
+     buttonSection: 'measurementSection',
+     groupId: 'MeasurementTools',
+   },
+ },
+
+ // 2. Register individual buttons separately
+ {
+   id: 'Length',
+   uiType: 'ohif.toolButton',
+   props: {
+     icon: 'tool-length',
+     label: 'Length',
+     tooltip: 'Length Tool',
+     commands: setToolActiveToolbar,
+     evaluate: 'evaluate.cornerstoneTool',
+   },
+ },
+ {
+   id: 'Bidirectional',
+   uiType: 'ohif.toolButton',
+   props: {
+     icon: 'tool-bidirectional',
+     label: 'Bidirectional',
+     tooltip: 'Bidirectional Tool',
+     commands: setToolActiveToolbar,
+     evaluate: 'evaluate.cornerstoneTool',
+   },
+ },
+

and then in your mode you can compose the section and associate buttons

+ // 3. In your mode, create the section and associate buttons
+ toolbarService.createButtonSection('primary', [
+   'MeasurementTools',
+   'Pan',
+   'Zoom',
+ ]);
+
+
+ toolbarService.createButtonSection('measurementSection', [
+   'Length',
+   'Bidirectional',
+   'ArrowAnnotate',
+   'EllipticalROI',
+ ]);

:::note
The measurementSection is defined in the tool button configuration of the MeasurementTools button.
:::

Group Evaluators Deprecated

Group evaluator functions like evaluate.group.promoteToPrimaryIfCornerstoneToolNotActiveInTheList are now deprecated. Instead, the uiType component itself is responsible for grouping and displaying the buttons from a section as needed. This allows for more flexible UI implementations that aren't tied to specific evaluation logic.

[netlify]

✅ Deploy Preview for ohif-platform-docs ready!

Name	Link
🔨 Latest commit	aabd117
🔍 Latest deploy log	https://app.netlify.com/sites/ohif-platform-docs/deploys/67c8a5aded5f790008da1c9c
😎 Deploy Preview	https://deploy-preview-4825--ohif-platform-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[netlify]

✅ Deploy Preview for ohif-dev ready!

Name	Link
🔨 Latest commit	aabd117
🔍 Latest deploy log	https://app.netlify.com/sites/ohif-dev/deploys/67c8a5ad81e0a40008bac4a3
😎 Deploy Preview	https://deploy-preview-4825--ohif-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[cypress]

Viewers    Run #4883

Run Properties:   Passed #4883  •  aabd1172ea: dd

Project	Viewers
Branch Review	feat/threshold-brush
Run status	Passed #4883
Run duration	03m 08s
Commit	aabd1172ea: dd
Committer	sedghi
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	0
Pending	2
Skipped	0
Passing	43
View all changes introduced in this branch ↗︎

[wayfarer3130]

Can you preserve the event? Otherwise it is difficult for some interactions to popup a localized menu etc.

[wayfarer3130]

Could we consistently use export * from './Toolbox'
so that it becomes easy to add new exports. That also means any types defined will get exported.

[wayfarer3130]

What about using useSystem() rather than withAppTypes? That separates the services used from the actual parameters.

[wayfarer3130]

If the ToolbarService is going to get modified like this, could we please use it to define the hierarchical toolbars?
That is, items such as "MeasurementTools" item should itself be defined as a button, but also use a nested toolbar to define it's contents with a toolbar called "MeasurementTools"

That is, the mode would have to register the "primary" toolbar but also "More Tools" toolbar, and the content of that would be the id's of the buttons included. That then makes the toolbar button definitions reuseable in multiple places, and allows defining alternate menu setups just be re-using the button definitions. Those button definitions should then all go into the extensions unless there are specific ones needing to be added in the mode that weren't already defined. I'm not asking for that second part to be done, just to make the toolbars actually recursive.

The MeasurementTools button parent class should then use useToolbar itself to get the list of tools to use at the time it is displayed.

[wayfarer3130]

Please use export * from './ToolboxUI'

[wayfarer3130]

I think this should stay MeasurementTools - what it means is that you want to put the "MeasurementTools" button there, which happens to useToolbar('measurementTools'), but that is an internal detail of the MeasurementTools button.

[wayfarer3130]

As suggested, this is still a button, so it uses the same casing as the other buttons.
The id of it is 'MeasurementTools' as a button.
The name of the button section to use is 'measurementSection'
They are different objects and shouldn't use the same names.

[wayfarer3130]

I don't think you should have to know anything about the nested button section - that update should be handled by an entirely different useToolbar, and should get the appropriate enhanced information when the toolbar is actually used.

[wayfarer3130]

I believe the way to make this order independent is to disconnect the sub items generation/fetch from the ToolbarService. Instead, I think it belongs in ToolButtonListWrapper as a simple useToolbar directive on the contained buttonSection id. That way the id of the toolbar item is completely independent of the actual button section id. In fact, one doesn't even know if it USES a nested list. All the logic for that is contained within the wrapper itself, and it becomes possible to write new wrappers that do other types of behaviours with the included items.