GUI Ideas

[apeltzer]

One idea would be to have a simple GUI that fetches a pipeline revision from this GitHub (e.g. with -r ) and then automatically offers the available params. entries as configurable options in dynamic GUI.

e.g. the GUI application just queries this Github and finds in main.nf some parameters to configure adapter clipping in more detail, thus we could provide a means to offer all these parameters in a GUI for end users in a dynamic way. Explanation of parameters could be done using a separate mapping file with <param.name, "GUI Name of param.name", "Short description", that we can gradually update too.

This way, we will always have a functional simple GUI application for end users that are not willing to use the CLI only + have the possibility to create a working JSON object for a specific pipeline version in the future too.

Let me know what you think @jfy133!

[jfy133]

So in laymans terms:

1. A user loads the GUI
2. The GUI asks the GitHub repo for the parameters that are currently compatible with the latest version of EAGER2.0
3. The GUI updates the main window with these parameters, and useful descriptions
4. The user goes through each section adding the information required
5. The user presses generate, and the EAGER2 config (JSON) file is created.

Let me know if that is a correct understanding.

I think it would also be good to have a config file 'viewer' for a user to review the settings have used in a particular run. I have my own personal bash script for this for EAGER 1.9, and I found this quite useful.

[apeltzer]

Yup, exactly my idea on this!

Regarding the viewer part - it would be quite easy to provide such a thing!

NXF provides a runtime report with all the parameters and we can write that out too - plus parsing a JSON object and displaying the same kind of information is also possible and could e.g. be a little student project.

[ewels]

This could be a cool idea to generalise and write into the nf-core tools package? If we define a standardised variable structure to hold config information required for the GUI (data type, description, helptext etc). The GUI could then generate either (a) a yaml/json file to be used with -params-file (this option appears to be undocumented?) or (b) a nextflow config file.

The second could be better, as then we'll also be able to define settings for the pipeline outside of the params scope.

Suggested example pipeline config:

params.reads = 'data/*_{R1,R2}.fastq.gz'
params.singleEnd = false
params.numIterations = 10
params.runName = 'My Test Run'

nfcore_gui {
    params {
        reads {
            type: 'file'
            required: true
            helptext: 'Path to the input data'
        }
        singleEnd {
            type: 'bool'
        }
        numIterations {
            type: 'num'
            min: 0
            max: 10
        }
        /* runName could be default: string, not required */
    }
}

The GUI could then take the default values from the config and use this to pre-fill the controls.

[apeltzer]

Yes, the -params-file is (as of now) undocumented. Thought that this could be a way to integrate with, but your second option seems more reasonable to me too!

I just wonder how big in terms of an effort it would be to create a simple (yet somewhat good looking GUI) out of this without confusing users too much. Should be feasible to hide advanced parameters to make the "main GUI" cleaner?

[apeltzer]

Oh and yes - I think this could very well be a general thing for nf-core tools! In fact I think that every pipeline could benefit from something like this

[apeltzer]

Continuing that discussion here, as it won't be EAGER only specific (phew!): nf-core/tools#61