Page MenuHomePhabricator

[worklist] mitk-flow preload first task
Closed, WontfixPublic

Description

Currently, when having only a worklist (even with only 1 element). The application opens empty and it is necessary "load" the first task.
It would be nice, if the worklist feature is activated (because of a worklist), the first item would be automatically loaded.
This could be the default behavior, if someone does not like it, in the preferences this could be deactivated.

Event Timeline

gaoh triaged this task as Wishlist priority.Dec 12 2022, 10:52 AM
gaoh created this task.

Without any extra preferences, it's as easy as adding the line this->LoadNextUnfinishedTask(); at the end of the OnTaskListChanged() method.

However, it has a side effect which I am not sure we are able to prevent as easy: Automatically loading a task this early in the lifetime of the Flowbench application happens before the Segmentation View executes its initial OnPreferencesChanged() method which explicitly calls Modify() on the data to enforce a rendering update of the contour or something like that (not nice). The Segmentation Task List widget in turn listens to this event to decide if the data was modified after loading, marking it as "dirty", resp. displaying the data status as "Unsaved changes" in the GUI. Even without actually changing anything, switching to the next task will summon a dialog questioning the user about how to proceed with the unsaved changes.

While the original issue is rather easy to resolve by exchanging the class to data->Modified() with a RequestRenderWindowAll() (which is the actual intent anyway according to the comments), more hurdles start to appear that are not as easy to resolve.

The data loading that is now happening immediately, is happening even before the rendering manager has any registered render windows. Any geometry validation of the data against render window geometries is a no-op, and it is kind of okay as it just works. However, when now adding another label in the GUI for example, the Segmentation View again does its data validation and now there ARE render windows with geometries and these do not match the segmentation geometry, resulting in the Segmentation View complaining about a necessary reinit (that is not necessary, yet is technically correct). There are many strategies to resolve this issue, none of them seem easy. The most straight-forward concept at least would be to defer loading of any data until the application is done with initializing its plugins and editors. That would probably require some kind of "ready" event triggered which could be used to load data specificied on the command-line.

Deleted branch from rMITK MITK: feature/T29432-PreloadFirstTask.

kislinsk raised the priority of this task from Wishlist to High.Jan 19 2023, 9:13 AM

Original issue resolved, raising priority and leaving open to discuss consequences in the next MITK meeting.

kislinsk lowered the priority of this task from High to Wishlist.
kislinsk added a subscriber: kislinsk.

Deleted branch from rMITK MITK: feature/T29432-PreloadFirstTask2.

kislinsk claimed this task.

While the original issue is rather easy to resolve by exchanging the class to data->Modified() with a RequestRenderWindowAll() (which is the actual intent anyway according to the comments), more hurdles start to appear that are not as easy to resolve.

The data loading that is now happening immediately, is happening even before the rendering manager has any registered render windows. Any geometry validation of the data against render window geometries is a no-op, and it is kind of okay as it just works. However, when now adding another label in the GUI for example, the Segmentation View again does its data validation and now there ARE render windows with geometries and these do not match the segmentation geometry, resulting in the Segmentation View complaining about a necessary reinit (that is not necessary, yet is technically correct). There are many strategies to resolve this issue, none of them seem easy. The most straight-forward concept at least would be to defer loading of any data until the application is done with initializing its plugins and editors. That would probably require some kind of "ready" event triggered which could be used to load data specificied on the command-line.

Closing for now as Wont Fix as it would require quite a lot of work and restructuring that does not match up the benefits at the moment.