Discussion result - Evaluate if in case of no selection (no labels), the highlight is enough to indicate a "selected group".

Discussion result - Decided on (a)

@gaoh With that already help you? Especially the last option with in file property lists and modify mode?
I would like to keep it in XML for now because it’s much faster to realize as we do not have to change complete reader infrastructure.

@gaoh PLease feel free to reopen if there is still a problem.

Turns out, eager plugins start too early to be of any use here (A). Regarding (B), preferences are already queried in the Workbench Window Advisors for the visibility of the category labels in tool bars, so it would be like two lines to get the preferences applied also at application startup, at the price of having to do it in each Workbench Window Advisor:

Since it is already buried in the Diff by Jenkins comments, I paste it here as well:

Pushed new branch to rMITK MITK: feature/T30284-ToolBarVisibilityThroughPreferences.

Pushed new branch to rMITK MITK: feature/T30253-sam-message-update.

Discussion result: Should be fixed with an exact calculation instead of an approximation based on histogram.

I just did the Pic3D/brain test mentioned above and it works with v2023.04.

We could set up a test case to check if it is still an issue in the context of segmentation task lists. A segmentation task list with two tasks, one task referencing Pic3D.nrrd, the other task referencing the tilted brain.nrrd image. If this is working with the latest release it should be a proof that is not an issue anymore.

In T29650#248947, @gaoh wrote:

@k656s has an example dataset. I am still at the release version before (I think 2022.10?) but I will update to the current release. Could this already help?

Yes, it could. I thought something like this was already introduced. @kislinsk, or?

@k656s has an example dataset. I am still at the release version before (I think 2022.10?) but I will update to the current release. Could this already help?
If not, I would vote for the task list view reinit after loading opiton.

@gaoh do you have example data to reproduce this situation. That would help to replicate it and search for the best solution.
Which version of MITK was it?

Option 2 seems not to be enough, since I still can paint in other windows, even though it makes a little difference at least. Also, while free drawing a segment, you can leave a window and place a control point outside of the image which leads to the crashes reported.

Pushed new branch to rMITK MITK: feature/T29604-sam-tool-2.

We should discuss if it is still worth it to get it back online after all this time and with the new tools.

We should discuss if we realy try to get region growing back online with all the other tools ...

This task should be revised / kept in mind when reworking the interpolation in general

This task should be revised / checked if the problem still exists when the interpolation controller has been reworked.

I pushed my local branch to remote for others to continue working on it. The related differential {D594} has been updated and will remain open.

From a first glimpse it really needs to be continued before merging. Can't make much sense right now out of mitk::StoreSCPLauncherBuilder in parallel to QmitkStoreSCPLauncher::Params. Have to take a closer look.

Should we integrate that in develop? Or any reason to wait?

In T24398#244802, @floca wrote:

Have you pushed your clean ups? Not that your efforts get lost. 😉

In T24398#242008, @kislinsk wrote:

In T24398#241998, @floca wrote:

Our side or also the CTK part.

Hm, lets put it as known issue and discuss its priority when we plan the spring release.

Only looked into our side so far. I'll create a separate task and push my clean-up that I already did so far.

A big leap into the Python direction would be to finally resolve T27923: Integrate possibility to execute Python Code in MITK , which is complete for a while now but we weren't able to figure out why it fails on Ubuntu build clients. Since the ITK v5 upgrade, we also need to adjust a little more I guess.

The plugin generator has been removed for now. Step 9 should be redesigned if the plugin generator was the blocker.

Removed the last remnants of the plugin generator.

Deleted branch from rMITK MITK: bugfix/T27701-RemovePluginGenerator.

Pushed new branch to rMITK MITK: bugfix/T27701-RemovePluginGenerator.

Deleted branch from rMITK MITK: bugfix/T27701-RemovePluginGenerator.

Pushed new branch to rMITK MITK: bugfix/T27701-RemovePluginGenerator.

@gaoh Please help me out. what was the final status of Elisabth's work here? Totaly dropped off the radar.

Would be nice if a note is added to the documentation that the MitkPluginGenerator is currently not active. :)