Quick fixes for the existing Executable / Despatcher UI

[johnhaddon]

• Replace ExecutableUI with a DespatcherUI
• Rename "despatcherParameters" to simply "despatcher"
• Address todo in StandardNodeUI about ExecuteButton creation
• Expose the requirement output plug
• Tidy up UI for existing ExecutableNodes (see Derive existing Writers and Renderers from ExecutableNode #864 for a list of nodes)

[johnhaddon]

This relates to #681, where I suggest I slight rejig of the Executable/ExecutableNode setup.

[andrewkaufman]

This tick box for replacing ExecutableUI (which doesn't exist, I assume it means ExecuteUI) with a DespatcherUI seems to be conflicting with a todo in StandardNodeUI, which wants to move some code to "a custom UI for the ExecutableNode". Almost all of what would be DespatcherUI would need to end up in ExecutableNodeUI. Shall I just rename ExecuteUI to ExecutableNodeUI, then add a new DespatcherUI for the despatcherPlug part of it?

[andrewkaufman]

Or do you think the Execute button (and menu items) should be provided by DespatcherUI? If that's the case, should I be defining a class called ExecutableNodeUI to hold the button on the main tab (as it is now) but put such a class in DespatcherUI? Or should DespatcherUI define something else (not a NodeUI class) that adds the button to the Despatcher tab instead?

[andrewkaufman]

Also, is ExecutableRenderUI intentionally hiding the requirement nodule or should that be fixed?

[johnhaddon]

Yep, let's rename ExecutableUI->ExecutableNodeUI. I think the menu items should probably be provided by DespatcherUI, and quite possibly the Execute button too.

Currently the Execute button just calls execute() directly on the node, without using a Despatcher of any kind. We need to decide whether or not we would like to keep this functionality, or whether execution should always go through a Despatcher. I think I'm inclined to the latter, so that preDespatchSIgnal() and postDespatchSignal() can be relied upon in all cases. If we do that, then we could add an option to the local despatcher - "execute in background", so that it's possible to execute either in the current session in a blocking way, or in a background process.

[johnhaddon]

I think I probably just hid the requirements nodule in ExecutableRenderUI because we don't have despatchers integrated yet, and it was confusing to expose something that doesn't actually do anything yet. We should expose it again when it works...

[andrewkaufman]

So... ExecuteUI -> ExecutableNodeUI, but the ExecuteButton (which is the current need for an ExecutableNodeUI class and makes up the bulk of the code in ExecuteUI) goes to DespatcherUI. Is that right? I guess it's all just commit history semantics then, so I might just keep my current (local) mess which moves ExecuteUI -> DespatcherUI, then adds ExecutableNodeUI as a new file, and steals some metadata lines from DespatcherUI.

Does DespatcherUI add the ExecuteButton to the Despatcher tab then? Users might not like that it's hidden away... or maybe they'll get used to tab toggling to access all the other plugs. Or can the DespatcherUI add headers which go above the tabs altogether so the ExecuteButton is always exposed?

[johnhaddon]

The history juggling you mentioned sounds fine to me - it seems like git will always decide what was moved based on similarity of file contents rather than anything else anyway.

I'd prefer the Execute/Despatch button to be on the main page rather than in the Despatcher tab as well. I think I'd want to be hitting that quite often, whereas I think the intention of the Despatcher tab was a place to set despatcher specific things like farm groups etc, which I would expect to be accessed less often. I guess we'll get a better feel for that sort of thing as we start to use Despatchers properly.

You can move the UI for any plug into the header above the tabs by setting the "nodeUI:section" metadata item to "header". It might make sense to have the execute button be the widget for the "requirement" (output) plug, and then we could use metadata to put it where we want.