[general need] Display the history of a file

[LStruber]

In the main database, instead of having a brick tag gives information about the (last) brick that created the file, it would be nice to be able to retrace a more complete history of the file by having a view of the pipeline which created the file (from pipeline inputs) (see discussion in #236).

To do that, we should replace the bricks tag button by a history button that will open a new window, where:

• the complete pipeline used to create the file is displayed (and each brick parameters is accessible)
• the direct brick ancestor of the file is highlighted in the pipeline
• information about this last brick are available (e.g. time of execution)

We could imagine that if we click on another brick in the pipeline view, we highlight it and then display information about the clicked brick instead of the last one. What do you think ?

Also do we need to display other information ? This is open to discussion.

[servoz]

We could imagine that if we click on another brick in the pipeline view, we highlight it and then display information about the clicked brick instead of the last one. What do you think ?

For me, this is a good idea. In the pipeline, as @denisri did, it is possible to have access to all the parameters of a brick/node by clicking on it and editing the controller (right click on the brick, open node controller). Adding at the bottom (for example) all the parameters of the brick (but not only because there would also be information on the initialisation and execution) is a very interesting idea. Moreover, at least in part, the codes already exist for that, since it is a bit what exists at the moment. Something like already discussed in the #236 ticket ?

[LStruber]

Yes, I pushed a modification in this direction into master. Next steps:

• highlight the last brick that created the pipeline
• if another brick is clicked, highlight it and update brick information at the bottom
• display the whole pipeline (need to work on #263 before)

In my opinion keeping the name of the last brick as the button name to click to show history is preferable than having a button named "history" at each line (too much redundancies). What do you think ?

[servoz]

Yes, it's nice !

This is a good starting point.

• So we would have in the top window the whole pipeline. Are you agree ?
• The corresponding brick would be highlighted.
• Currently if we open the controller, it is behind all the windows. It would be better if it appeared in the foreground.
• Do we want to be modal or not ? (may be modal, no ?)
• etc..

[LStruber]

So we would have in the top window the whole pipeline. Are you agree ?

Yes

Currently if we open the controller, it is behind all the windows. It would be better if it appeared in the foreground.

I also noticed it, and to close the node controller window, you have to close the history window. I don't know why it happens this way since the node controller is directly handled by the pipelinedeveloperview object. I think we'll need to dig a bit into this view to make it appear in the foreground. Maybe @denisri has an idea on this point ?

Do we want to be modal or not ? (may be modal, no ?)

I do not understand this question, what does modal mean ?

[denisri]

Modal means that the window is a kind of popup dialog, which stays at the top level, and normally disables all other windows during its edition, thus is is blocking the rest of the app. It is meant for local (short time) questions asked to the user, where the answer is needed before going further. It is not suitable for a window that stays visible while the rest of the application should continue to work. So I'd say: no the history window does not have to be modal.

[LStruber]

Thank you for the explanation and sorry for the missing vocabulary !

[servoz]

ahem ... if we are non-modal, it will mean that the user can go back to the DataBrowser and open another history for another data at the same time ... Why not, let's start with non-modal and see what it looks like in use.

[denisri]

ahem ... if we are non-modal, it will mean that the user can go back to the DataBrowser and open another history for another data at the same time ... Why not, let's start with non-modal and see what it looks like in use.

We may have several history windows open at the same time, why not after all if the user wants to compare several histories. Otherwise we can decide to reuse (or close/reopen) the same window when the user clicks on the history button of another data, without it being modal. Modal dialogs should preferably be reserved to short time, temporary dialogs, or at least dialogs where the result is expected and needed to continue another operation, or to prevent concurrent modification of the data they display (like preferences). Otherwise modal dialogs have several drawbacks: they stay on top of the widget stack, thus we cannot easily see other widgets underneath, and if we have too many of them there is a risk of having several modal dialogs displayed at the same time.

[servoz]

We may have several history windows open at the same time, why not after all if the user wants to compare several histories. Otherwise we can decide to reuse (or close/reopen) the same window when the user clicks on the history button of another data, without it being modal. Modal dialogs should preferably be reserved to short time, temporary dialogs, or at least dialogs where the result is expected and needed to continue another operation, or to prevent concurrent modification of the data they display (like preferences). Otherwise modal dialogs have several drawbacks: they stay on top of the widget stack, thus we cannot easily see other widgets underneath, and if we have too many of them there is a risk of having several modal dialogs displayed at the same time.

OK !

[LStruber]

Can we consider that the display of the history fits our needs ?

• separation between brick row and pipeline view
• highlighting the selected brick
• displaying brick information

If yes, I think we can close this ticket, and focus on resolving remaining issues of ticket #263

[servoz]

Ok for me!