Currently the UpdateStatusBar method in QmitkImageNavigatorView and in mitkDisplayInteractor mitkDisplayActionEventBroadcast duplicate a lot of business logic. The part of the function that extracts the pixel value from the image and updates the statusbar is the same. The redundant part should be extracted and be put in one function that can be called by both (QmitkImageNavigatorView::UpdateStatusBar() and mitkDisplayInteractor::UpdateStatusBar() mitkDisplayActionEventBroadcast::UpdateStatusBar().
Similar code is also used inside StdMultiWidget::HandleCrosshairPositionEventDelayed, where the image / pixel information is extracted and passed onto mitkStatusBar.
Description
Description
Revisions and Commits
Revisions and Commits
| rMITK MITK | |||
| Restricted Differential Revision | rMITK7b8c4c8af97d Remove duplicated UpdateStatusBar logic | ||
| Restricted Differential Revision | rMITKdced93baf4c9 Use time-specific data type | ||
| Restricted Differential Revision | rMITKb309cff2567b Perform simple statusbar update on mouse move / wheel event | ||
| Restricted Differential Revision | rMITKd527ccc37170 Add function to simply display the world position and time | ||
| Restricted Differential Revision | rMITK10d3b3205edb Remove status-bar update from the ImageNavigatorView | ||
| Restricted Differential Revision | rMITK722a5b4dc96b Remove unnecessary includes and comments | ||
| Restricted Differential Revision | rMITKdd5b3d989db1 Remove unused CrosshairPositionEvent | ||
| Restricted Differential Revision | rMITK7e92f5e3dd09 Remove status-bar update from the StdMultiWidget | ||
| Restricted Differential Revision | rMITKe8d06e901d49 Remove update-function from the DisplayActionEventBroadcast | ||
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | kalali | T25105 UpdateStatusBar duplicates business logic | ||
| Resolved | kalali | T25043 Remove pixel informations from the statusbar and put it into views |
Event Timeline
Comment Actions
This should be fixed in conjunction with T25042: How to handle update informations in heterogeneous time geometries and out of bound situations and T24767: Workbench crashes when loading two 3D+t images with different number of time steps, because an unfixed UpdateStatusBar in the DisplayInteractor could also cause crashes like in T24767.
Comment Actions
The GetTopLayerNode has been moved to the data storage as FindTopmostVisibleNode.
Would it be reasonable to move the UpdateStatusBar functionality to the data storage as well, as it needs to extract image information from the topmost visible node?
Or is there some other place for this kind of image geometry processing?
Comment Actions
No, I don't think so. It is not job of the DataStorage to update the status bar.
Or is there some other place for this kind of image geometry processing?
UpdateStatusBar is not just image geometry processing.
Why not put it in mitkStatusBar.h? E.g. as global public method or put it into a mitkStatusBarHelper
I think both ways are more appropriate then putting it into the DataStorage or its files.
Comment Actions
We do not need to move the whole functionality to the data storage, just the geometry processing part. The rest can be put somewhere else, but https://phabricator.mitk.org/D14 said, It was decided that the status bar should not be responsible for extracting information from an image.
So basically I was thinking about a function inside the data storage that would do the image processing and the compute / return the needed parameters to call DisplayImageInfo.
Comment Actions
What do you exactly mean with geometry processing part? Does "to the storage" mean, into the class or into the file?
The rest can be put somewhere else, but https://phabricator.mitk.org/D14 said, It was decided that the status bar should not be responsible for extracting information from an image.
Please take care. I never said it should be part of the class StatusBar. I proposed that it should be a global public method in the header file mitkStatusBar.h. Thats a big difference in terms of dependencies etc.
So basically I was thinking about a function inside the data storage that would do the image processing and the compute / return the needed parameters to call DisplayImageInfo.
If you plan any rework, please keep T25043: Remove pixel informations from the statusbar and put it into views in mind. As discussed there the pixel information should not be in the status bar at all and is very use case, application specific.
Comment Actions
In combination with the child task I added a first part of the tasks in D686.
The UpdateStatusBar-functions (and HandleCrosshairPositionEventDelayed-function) are completely removed and a simple function has been added to dynamically write the pointer position / world position and the global time to the status bar.
More changes will be uploaded to show an example of how image pixel information could be added to the renderer as an overlay or how a specific image pixel info widget / view could look like.