search

populse / populse_mia

Multiparametric Image Analysis
Other
10 stars 9 forks source link

[Pipeline history] Node controller inputs/outputs should be populated in history windows #267

Closed servoz closed 10 months ago

servoz commented 2 years ago

Currently, only the inputs and outputs of the pipeline are filled in the node controller. It would be desirable that, in the history window, all inputs and outputs for each node of the pipeline would be available in the controller. For now, the node controllers are disabled in the history window. When this ticket will be processed, we could make the nodes controllers available again in the history window

servoz commented 10 months ago

The history window consists of a pipeline view at the top and a table with input and output parameters at the bottom.

Following the latest modifications, the input and output parameters, of the brick that generated the data whose history we want to see, are correctly displayed in the table.

history_1

There is a hard-coded attribute (banished_param) which groups together the parameters we don't want to see. All the other parameters are displayed in the table (even those that are not seen by the user in a brick - userlevel>0 -, which can be interesting for an advanced user in certain cases).

Now things seem to be working properly except when it comes to a brick at a lower level than n-1 in the pipeline.

If it is an n-1 level brick (e.g. pipeline_name.brick_name), after selecting in the data browser the data to explore, the history window opens with this brick highlighted and the parameters for this brick (vide supra fig.). It is then possible to click on another brick in the pipeline, and things work fine if it is still an n-1 level brick.

Things get more complicated if the brick is > n-1 level.

If we select data corresponding to a level > n-1 (let's say n-2, for example pipe_name_1.pipe_name_2.brick), the history window opens with the brick parameters, but the pipeline view is that of level n-1 and only the pipeline containing the brick is highlighted:

history_2

Since we're at level n-1, it's possible to click on a brick at this level and things will happen as described above. On the other hand, in the history window we can't access a brick located in a sub-pipeline at this level (n-2). Indeed, in this case: 1- the right click sub-pipeline option is not available 2- if we click on this sub-pipeline the result currently looks like a bug (no parameters displayed):

history_3

I've written this somewhat detailed summary in order to provide an update on the current functionality of the history window, but also because I'm not sure how the history window should evolve ...

If we select a data in the data browser, I think it's to get an overview of the pipeline and the parameters of the brick that created the dataset. It works perfectly now.

But ... When we have something we want something better, and that's good because it makes things better. But sometimes "the best is the enemy of the good". We would therefore like to be able to navigate, in the history window, inside the pipeline to see it at levels > n-1 and consult the parameters at these levels. However, does this make sense?

Indeed the user can use the pipeline manager for this, of course he will not have access to the parameters used during the creation of the data. But as the history window is non-modal it is still possible to open the pipeline manager with the pipeline and consult the history window at the same time. It's a bit heavy and not very elegant but it's possible.

Also, conceptually, walking through the pipeline in the history window means looking at something other than the initial data that caused the history window to open (although that may be related). Does it really make sense to do this, when we can just close the history window and open another one from the data browser for another data? Once again it's not very elegant but it's possible.

Finally, the history window is based on the workflow object which is instantiated at the time of pipeline execution. If after this execution the pipeline disappears from the library, there will no longer be access to the history. To do really well we would have to save the pipeline at run time because currently if the pipeline no longer exists in the library the user cannot consult what created the data.

In short, given that we have many other priorities to manage I think that we really have to be sure that we have to launch into these improvements, knowing that the existing one is working correctly and that these improvements will take time lost for others thing ...

What I can do for the moment and which should not take very long is to put a small message indicating that we can only display the pipeline at level n-1 and that for this we must use the pipeline manager, if the user clicks on a pipeline in the history window (in order not to have a bug feeling). There remains the problem of lost history if the pipeline or a brick constituting it is no longer in the library.

All suggestions are welcome ...

I'm closing this ticket for now, if there is a discussion we can reopen it!

servoz commented 10 months ago

I didn't really like the feeling of a bug if we click on a pipeline in the history window, nor the idea of putting a message as a patch. Now, if the user clicks on a pipeline, he'll see the pipeline's input and output parameters. I think that's better. The questions in this ticket remain open. Let's see if it makes sense and if we want to spend development time on it.