Hi Will,
> I am trying to use protocol, but I found that the interaction in Protocol is not so good, many interact-oriented protocol is not so convenient now, for example drawing ROIs in protocol.
The "non-interactivity" of Protocols is by design, but this is still an open debate. My initial idea in designing Protocols was that the full pipeline of information and processing steps should remain static once it runs (i.e. non-linked parameters cannot change anymore). There are 2 intermingled reasons behind this design:
- Reproducibility/Readability: the protocol that you use, or send to a collaborator, or publish online, should be the same for everyone. Whether you adjust the value of a parameter here or there or keep it unchanged, this will affect the final output of the protocol, but it remains essentially the same protocol, which runs identically on all your images (see second point). This is also the reason why I did not (yet, although it's in the back of my head) implement branches (if/else), because assuming you run a batch on 1000 of images, and you have a "if/else" that filters out the information, you will not be sure which result came from which branch, that info isn't currently stored (I could think about it though).
- Batch/Offline: an interactive protocol would, by definition, ask for user-interaction. To take the previous example of running on 1000 images, having the user double-check "anything" 1000 times sounds like counter-productive to me, and against the very idea of batch processing. This problems becomes all the more obvious when you think of running protocols offline on clusters, where no interaction is possible. You would then have to indicate which protocols are interactive, and which aren't... and we're back to the simplicity item.
> I am wondering is it possible to define a GUIs in protocol and each component can be linked to the blocks. Maybe I can use Python or JS to define a GUI, and it appears in protocol as a block, and I can link each component to other blocks, and I can press the run button on GUI. Just like Labview does, use EzGUI as the interface, and protocol run in the background.
> These will be really useful for user, and this will produce another way to make new plugin, I mean, anyone can pack their protocol and GUI as a plugin.
If I understand correctly, then I believe this *is* already possible to have your own parameter and associated GUI inside protocols. You basically have to create a new Var object that fits your needs, and attach a custom GUI component to it (have a look at the EzPlug API, and also in the source code of the Workbooks plugin for a shorter, concrete example of a plugin that delivers a EzGUI but also a block with a custom GUI). Note however that as per the previous remarks, the GUI would only be usable before you start the protocol, and not while it is running.
The fully interactive alternative (for now) is via scripts, where you may indeed have the script wait for some user interaction (some of the sample scripts online already do that).
Hope that clarifies a bit, let me know your thoughts,
cheers
Alexandre