diff --git a/extensions/cornerstone/src/components/WindowLevelActionMenu/Colormap.tsx b/extensions/cornerstone/src/components/WindowLevelActionMenu/Colormap.tsx index b6a81eb81..6bf57c324 100644 --- a/extensions/cornerstone/src/components/WindowLevelActionMenu/Colormap.tsx +++ b/extensions/cornerstone/src/components/WindowLevelActionMenu/Colormap.tsx @@ -27,7 +27,6 @@ export function Colormap({ const onSetColorLUT = useCallback( props => { - debugger; // TODO: Better way to check if it's a fusion const oneOpacityColormaps = ['Grayscale', 'X Ray']; const opacity = diff --git a/platform/docs/docs/migration-guide/3p9-to-3p10/General/commands.md b/platform/docs/docs/migration-guide/3p9-to-3p10/General/commands.md new file mode 100644 index 000000000..814692669 --- /dev/null +++ b/platform/docs/docs/migration-guide/3p9-to-3p10/General/commands.md @@ -0,0 +1,53 @@ +--- +title: Commands +--- + + +# Commands + +## Measurements + +* The `deleteMeasurement` command has been completely removed from the codebase It has been replaced by `removeMeasurement` command with enhanced functionality + +1. Replace any usage of `deleteMeasurement` with `removeMeasurement` in your custom code + +```diff +- commandsManager.run('deleteMeasurement', { uid }); ++ commandsManager.run('removeMeasurement', { uid }); +``` + + +## Important Notes: + +* This change is part of a broader refactoring of the measurement system to provide more consistent and powerful APIs +* The new command structure follows a more consistent pattern throughout the codebase +* If you were using `measurementServiceSource.remove(uid)` directly, you should now use `measurementService.remove(uid)` instead +* The changes affect both UI components and any extensions that integrate with the measurement system +* Removal functionality now works with both individual UIDs and arrays of UIDs for batch operations + + + +## `setSourceViewportForReferenceLinesTool` + +* `setSourceViewportForReferenceLinesTool` has been replaced by the more generic `setViewportForToolConfiguration` +* The new API allows configuration of any tool, not just the ReferenceLinesTool +* Tool name is now a required parameter, not hardcoded to ReferenceLinesTool + +## Migration Steps: + +1. Update command references from `setSourceViewportForReferenceLinesTool` to `setViewportForToolConfiguration` + +```diff +- { +- commandName: 'setSourceViewportForReferenceLinesTool', +- context: 'CORNERSTONE', +- } + ++ { ++ commandName: 'setViewportForToolConfiguration', ++ commandOptions: { ++ toolName: 'ReferenceLines' ++ }, ++ context: 'CORNERSTONE', ++ } +``` diff --git a/platform/docs/docs/migration-guide/3p9-to-3p10/General/general-m.md b/platform/docs/docs/migration-guide/3p9-to-3p10/General/general-m.md new file mode 100644 index 000000000..22b7512ac --- /dev/null +++ b/platform/docs/docs/migration-guide/3p9-to-3p10/General/general-m.md @@ -0,0 +1,118 @@ +--- +sidebar_position: 1 +title: General +--- + +## Node.js Version Update + +We have updated the recommended Node.js version from `18.16.1` to `20.9.0`. Please ensure your development and build environments are using Node.js `20.9.0` or later. + +## HTML Template Update +We have modified the `template.html` file so if you are using a custom template, you will need to update it. + +Here are the key changes needed in the migration: + +1. Added `window.PUBLIC_URL` declaration: +```javascript +window.PUBLIC_URL = '<%= PUBLIC_URL %>'; +``` + +Was added before the `` comment block. + +## Bundled Google Fonts + +Previously, OHIF relied on the Google Fonts API to load the required fonts. To improve privacy, performance, and offline availability, we now bundle the necessary font files as assets within the application. No explicit action is required for this change unless you were specifically overriding or manipulating the font loading process. + +You **might** need to update your `module` rule in your webpack + +```javascript +module.exports = { + module: { + rules: [ + { + test: /\.(woff|woff2|eot|ttf|otf)$/i, + type: 'asset/resource', + }, + ], + }, +}; +``` + + + + +## OHIF Docs + +OHIF platform/docs is no longer part of the workspace. + +- Builds are faster for 99.99% of users since only maintainers need to run the docs development. + +If you need to run the docs website locally, you must install it first, as it is not installed by default. + +Before: +```bash +yarn run dev +``` + +After: +```bash +yarn install +yarn run dev +``` + + +## Experimental Fast Development Build (`dev:fast`) + +We have introduced a new experimental command, `yarn run dev:fast`, which utilizes `rsbuild` and its Rust-based approach to significantly speed up development server start and hot module replacement times. + +Here's a comparison of the performance improvements: + +| Scenario | Load Time | Update Time | +| -------- | ----------- | ----------- | +| Before | ~12 seconds | ~5 seconds | +| After | ~4 seconds | ~1 second | + +**Note:** This command is currently experimental. While functional, it may not yet support all features or configurations of the standard `yarn run dev` command. We are continuing to develop and test this feature. + + +## Webpack Configuration + +To use our new Segmentation AI models, you'll need `onnxruntime-web`. If you're using a custom webpack configuration, make sure to update it with the new `copyPlugin` to copy the `onnxruntime-web` `dist` folder to your output directory. + + +```javascript +const CopyPlugin = require('copy-webpack-plugin'); + +module.exports = { + plugins: [ + new CopyPlugin({ + patterns: [ + { + from: '../../../node_modules/onnxruntime-web/dist', + to: `${DIST_DIR}/ort`, + }, + ], + }), + ], +}; +``` + +Also, if you're running the viewer from a sub-route, you'll need to update the `dicom-microscopy-viewer` package in the dev server, so it knows where to load the assets from. + + +```javascript +devServer: { + proxy: { + '/dicom-microscopy-viewer': { + target: 'http://localhost:3000', + pathRewrite: { + '^/dicom-microscopy-viewer': `/${PUBLIC_URL}/dicom-microscopy-viewer`, + }, + }, + }, +}, +``` + +:::note +Also, the `writePluginImportFile` function has been updated so that the dicom-microscopy-viewer package works correctly with the new webpack configuration. If you have a custom `writePluginImportFile` function, please update it to match. +::: diff --git a/platform/docs/docs/migration-guide/3p9-to-3p10/General/index.md b/platform/docs/docs/migration-guide/3p9-to-3p10/General/index.md deleted file mode 100644 index 1689d2bf3..000000000 --- a/platform/docs/docs/migration-guide/3p9-to-3p10/General/index.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -sidebar_position: 1 -title: General ---- - -## HTML Template Update -We have modified the `template.html` file so if you are using a custom template, you will need to update it. - -Here are the key changes needed in the migration: - -1. Added `window.PUBLIC_URL` declaration: -```javascript -window.PUBLIC_URL = '<%= PUBLIC_URL %>'; -``` - -Was added before the `` comment block. - - -## OHIF Docs - -OHIF platform/docs is no longer part of the workspace. - -- Builds are faster for 99.99% of users since only maintainers need to run the docs development. - -If you need to run the docs website locally, you must install it first, as it is not installed by default. - -Before: -```bash -yarn run dev -``` - -After: -```bash -yarn install -yarn run dev -``` - -## CommandsModule - -1. Removed the `deleteMeasurements` command from the `CORNERSTONE` context. It should be replaced by `removeMeasurements` command. diff --git a/platform/docs/docs/migration-guide/3p9-to-3p10/UI/1-Introduction.md b/platform/docs/docs/migration-guide/3p9-to-3p10/UI/1-Introduction.md new file mode 100644 index 000000000..230c78d3a --- /dev/null +++ b/platform/docs/docs/migration-guide/3p9-to-3p10/UI/1-Introduction.md @@ -0,0 +1,21 @@ +--- +title: Introduction +position: 1 +--- + + +## Introduction + +The OHIF Viewer has two main parts: the worklist and the image viewer. + +In version 3.10, we successfully migrated the image viewer to the `@ohif/ui-next` library. This is a complete rewrite of each component, offering extensibility, accessibility, and a modern look and feel. + +The worklist is still using the old `@ohif/ui` library, but it will be migrated to `@ohif/ui-next` in a future release. + +## Migration Guide + +You'll generally need to update your custom panels to use the new `@ohif/ui-next` components. + +The task is to find the direct mapping of the components you're using in your custom panels. + +This guide will cover the migration for them. diff --git a/platform/docs/docs/migration-guide/3p9-to-3p10/UI/Migration-3p10-Tests.md b/platform/docs/docs/migration-guide/3p9-to-3p10/UI/10-Migration-3p10-Tests.md similarity index 100% rename from platform/docs/docs/migration-guide/3p9-to-3p10/UI/Migration-3p10-Tests.md rename to platform/docs/docs/migration-guide/3p9-to-3p10/UI/10-Migration-3p10-Tests.md diff --git a/platform/docs/docs/migration-guide/3p9-to-3p10/UI/1a-Colors.md b/platform/docs/docs/migration-guide/3p9-to-3p10/UI/1a-Colors.md new file mode 100644 index 000000000..ea98850b0 --- /dev/null +++ b/platform/docs/docs/migration-guide/3p9-to-3p10/UI/1a-Colors.md @@ -0,0 +1,73 @@ +--- +title: Colors +--- + + +**Key Changes:** + +* **New Color System:** Migration from custom color names (e.g., `aqua-pale`, `common-bright`) to a semantic color palette using CSS variables (e.g., `--primary`, `--secondary`, `--muted-foreground`). Tailwind classes like `text-primary`, `bg-secondary`, `text-muted-foreground` should now be used. +* **Deprecated Color Classes:** Custom color classes like `text-aqua-pale` and `text-common-bright` have been removed and need replacement. +* **Simplified State Classes:** Explicit hover/active state classes like `bg-primary-main`, `hover:bg-primary-light`, `active:text-primary-light` seem to be replaced by simpler base classes (e.g., `bg-primary`) where Tailwind's state variants (`hover:`, `active:`) modify the base color, or these states are handled by component variants (e.g., in a Button component). +* **Component Abstraction:** Some styling, especially for interactive elements like buttons, has been abstracted into components (e.g., `ViewportActionButton`, UI library buttons) which use predefined variants (`default`, `secondary`, `ghost`) instead of manual style combinations. + +:::note +You can look at the set of colors in the [Color System](/colors-and-type) +::: + + +**Migration Steps:** + +1. **Identify Deprecated Color Classes:** + Search your codebase for the old custom color classes. The most common ones identified in the diff are: + * `text-aqua-pale` + * `text-common-bright` + * `text-primary-active` + * `bg-primary-main` + * `hover:bg-primary-light` + * `hover:text-black` (when used with primary hover states) + * Potentially others using similar custom names. + +2. **Replace with New Semantic Colors:** + Update the deprecated classes with their likely semantic equivalents from the new system. Use the table below as a guide. **Note:** The exact replacement might depend on the specific context and desired visual outcome. Inspect the element in the browser after changes to ensure it matches the intended design. + + | Old Class | Likely New Class(es) | Notes | + | :------------------------ | :-------------------------------------------------------- | :-------------------------------------------------------------------- | + | `text-aqua-pale` | `text-muted-foreground` | Used for less prominent text, now uses the muted foreground color. | + | `text-common-bright` | `text-foreground` or `text-primary-foreground` | Likely the default bright text color. | + | `text-primary-active` | `text-primary` or `text-highlight` | Simplified to the base primary color or potentially a highlight color. | + | `bg-primary-main` | `bg-primary` | Simplified to the base primary background color. | + | `text-white` (on dark bg) | `text-foreground` or `text-primary-foreground` | Use the standard foreground color for the theme. | + | `bg-black` (for elements) | `bg-background`, `bg-popover`, `bg-card`, or `bg-muted` | Use semantic background colors depending on the element's role. | + +3. **Update State Variants and Interactions:** + Classes managing hover, active, or focus states have likely been simplified or moved into component variants. + + * **Remove Explicit Hover/Active Styles:** Search for combinations like `hover:bg-primary-light`, `hover:text-black`, `active:text-primary-light` and remove them if the element now uses a base class like `bg-primary` or component variants. Tailwind's built-in state modifiers (`hover:`, `active:`) might handle this automatically with the new base colors, or component variants encapsulate these states. + * **Use Component Variants:** If the element is now a component from a UI library (like `Button` from `@ohif/ui-next`), use its variants (`variant="default"`, `variant="secondary"`, `variant="ghost"`) instead of manual style combinations. + + *Example Diff:* + ```diff + -
+ - Action Button + -
+ + + + ``` + + *Example Diff:* + ```diff + // Before (in _getStatusComponent.tsx) + -
+ - {loadStr} + -
+ + // After (in OHIFCornerstoneRTViewport.tsx using the abstracted component) + + + + {loadStr} + + + ``` diff --git a/platform/docs/docs/migration-guide/3p9-to-3p10/UI/Migration-3p10-Icons.md b/platform/docs/docs/migration-guide/3p9-to-3p10/UI/2-Migration-3p10-Icons.md similarity index 100% rename from platform/docs/docs/migration-guide/3p9-to-3p10/UI/Migration-3p10-Icons.md rename to platform/docs/docs/migration-guide/3p9-to-3p10/UI/2-Migration-3p10-Icons.md diff --git a/platform/docs/docs/migration-guide/3p9-to-3p10/UI/2a-Migration-3p10-Button.md b/platform/docs/docs/migration-guide/3p9-to-3p10/UI/2a-Migration-3p10-Button.md new file mode 100644 index 000000000..887966a14 --- /dev/null +++ b/platform/docs/docs/migration-guide/3p9-to-3p10/UI/2a-Migration-3p10-Button.md @@ -0,0 +1,125 @@ +--- +title: Button +--- + +## Key Changes: + +* **Component Library:** The primary `Button` component likely now resides in `@ohif/ui-next` instead of `@ohif/ui`. Imports need to be updated. +* **`ButtonEnums` Deprecated:** The `ButtonEnums.type` (e.g., `ButtonEnums.type.primary`) used for button styling is deprecated. Styling is now primarily controlled by the `variant` prop using string literals (`'default'`, `'secondary'`, `'ghost'`, `'link'`). +* **Styling Approach:** Manual Tailwind CSS classes for styling (colors, hover states, sizing) are largely replaced by the `variant` and `size` props on the new `Button` component. Semantic color names are used internally. +* **`IconButton` Replacement:** The pattern of using a dedicated `IconButton` component is often replaced by using ` + ``` + +5. **Replace `IconButton`:** + Update instances of `` to use ` + ``` + +6. **Replace `ButtonGroup` with `Tabs`:** + Refactor sections using `ButtonGroup` to use the `Tabs`, `TabsList`, and `TabsTrigger` components. Manage the selected state using the `value` and `onValueChange` props of the `Tabs` component. + + *Example (`DynamicVolumeControls.tsx` change):* + ```diff + - + - + - + - + + + setComputedView(value === 'computed')} + + className="my-2 w-full" + + > + + + + 4D + + Computed + + + + + ``` + +7. **Identify Specific Component Replacements:** + Review areas where styled `div` elements were used as buttons. Replace them with appropriate components like ` + + + + + + Cancel + + + + + ``` diff --git a/platform/docs/docs/migration-guide/3p9-to-3p10/UI/3-Migration-3p10-Input.md b/platform/docs/docs/migration-guide/3p9-to-3p10/UI/3-Migration-3p10-Input.md new file mode 100644 index 000000000..bc4816cea --- /dev/null +++ b/platform/docs/docs/migration-guide/3p9-to-3p10/UI/3-Migration-3p10-Input.md @@ -0,0 +1,378 @@ +--- +title: Input +--- + + +# Migration Guide: Input Components to @ohif/ui-next + +This guide explains how to migrate from the existing `Input`, `InputNumber`, `InputRange`, `InputDoubleRange`, `InputFilterText`, `InputGroup`, `InputLabelWrapper`, and `InputText` components to their new equivalents or patterns using `@ohif/ui-next`, including the `Numeric` meta component for numeric inputs. + + + + +## Why Migrate? + + See the full list of components in the [Numeric Component Showcase](/components-list#numeric) + + +The old components relied heavily on props, making them complex and difficult to maintain and apply custom styles. The new `Numeric` component provides a structured approach with a context-based API, reducing prop clutter and improving reusability. + +The `Numeric` component offers several advantages: +- **Versatile Modes**: It supports basic number input (`Numeric.NumberInput`), stepper controls (`Numeric.NumberStepper`), single range sliders (`Numeric.SingleRange`), and double range sliders (`Numeric.DoubleRange`). +- **Flexible Layout**: You have full control over the layout using standard CSS classes (`className`) on the container and its subcomponents like `Numeric.Label`, `Numeric.NumberInput`, etc., allowing for various arrangements (e.g., flex, grid). +- **Enhanced Customization**: Easily customize the appearance and behavior, such as showing/hiding associated number inputs for sliders, displaying the current value within the label (`showValue`), and integrating icons. +- **State Management**: Supports both controlled and uncontrolled component states. + + + + +## `Input type="number"` > `Numeric.NumberInput` + +### Basic Usage + +**Old Usage:** + +```tsx + setValue(e.target.value)} + type="number" +/> +``` + +**New Usage:** + +```tsx + + Enter a number + + +``` + + + +### `Input` with Custom Classes + +#### **Old Usage (with containerClassName, labelClassName, and className)** + +In the old implementation, we manually applied `containerClassName`, `labelClassName`, and `className` to style the `Input` component: + +```tsx + setValue(e.target.value)} + type="number" + containerClassName="flex flex-col space-y-2" + labelClassName="text-gray-500 text-sm" + className="border rounded p-2" +/> +``` + + +**New Usage (Migrating to `Numeric.NumberInput`)** + +With `Numeric`, you should wrap everything inside `Numeric.Container`, and you can directly apply class names to its subcomponents: + +```tsx + + Enter a number + + +``` + + +## `Input` / `InputText` (General) > `@ohif/ui-next Input + Label` + +**Key Changes:** + +* The base `Input` component from `@ohif/ui` is replaced by the `Input` component from `@ohif/ui-next`. +* Styling props like `labelClassName`, `containerClassName` are removed. Use standard `className` on the `Input` component and its container elements. +* Labels provided via the `label` prop are removed. Use the separate `Label` component from `@ohif/ui-next` alongside the `Input`. +* Layout is handled by standard HTML/Tailwind (Flexbox, Grid). + +**Migration Steps:** + +1. **Update Import:** Ensure you are importing `Input` and `Label` from `@ohif/ui-next`. +2. **Replace Label Prop:** If you used the `label` prop, add a separate `