We have discussed that task. It was agreed that the statusbar is not the right place to put this information. It was also agreed that the feature (showing the value of the current position) should not be skipped and is used in many applications.

Possible solutions (ordered by favor/approval):

1. The information should be displayed in the render window directly as an overlay.
2. We make a dedicated view that displays the information (as mentioned in the task description)

We again concluded that this information + some optional extra features should be shown by a view instead of the task bar. The idea is to have a kind of "core" view like the slice navigator that is usually shown in all perspectives but in the end is configurable.

In T25043#239851, @kalali wrote:

1. Do we agree that there will be no position / pixel value information shown in the status bar?
   1. or are we only talking about the (maybe case-specific) pixel value information; meaning the position / index should still be shown in the status bar?
   2. if everything should be removed from the status bar, we wouldn't put any new functions in the "StatusBar"-class, right?

I would say A. So coordinate information is still visible.

1. If we keep the position / index in the status bar, we could still have a problem with mxnMultiWidget and multiple, independent render windows
   1. so we could put the position / index into the render windows (as overlay) as well

I think we have to differentiate here.
A general "pointer to a special point in world coordinate space" makes still sense. And some view also need something like that (e.g. the ModelFit inspector) where you can navigate in space.
But that does not mean that every render window have to show this cursor or have to show it on the same location.

I would see it like that.

• The workbench has one "cursor/crosshair" that marks a special point in "space time" (so a position in world coordinate and time geometry). You can e.g. still manipulate it via the navigators view.
• Each render window has its own setting:
  • should I show that cursor
  • Transform for the "space time" position (in general it is identity, but it could be transformed, for what ever reason; e.g. in space to show the registered position in an original image, or in time because you want to show the frame ahead)
  • a base image/geometry

1. As mentioned in T29220: StatusBar info is dependent on the pointer position, not on the crosshair / mouse click, we currently have some unexpected behavior. However, I like to be able to see the position / index and pixel value information dynamically while the mouse pointer moves. This is possible, I already implemented a quick first solution for this. However, we have to decide if we want this behavior or only show the index / pixel value information for the crosshair.

Dynamic mouse position can be helpfull, yes. For pixel I think it is still to depending on the use case, what the pixel is, you are interested in.

1. @s434n and I also discussed, if a crosshair for mxnMultiWidget is even required,

I would say, yes. See comment above. Also pixel value inspection could be another use case that favors a generic position indicator. Because it makes live easier to correctly render corresponding pixelvalues in an application specific view. Otherwise you would to do everything in render window specific overlays.

Just my 2 cents.

I connected this task with D686: Not all discussed points are handled here but I removed the UpdateStatusBar-functions completely and added a simple function to update the status bar info with the mouse pointer / world position and the global time dynamically.
More code changes will be uploaded to provide ideas on how to show image pixel information.

Pixel information has been removed with {D686}. We discussed that we will open a new task to add a simple pixel value information view as a separate task.

Pixel information has been removed. To add a specific view for pixel information, see T29324: Create view for pixel information.