Feedback on connectors and outputs in the GUI from hackathon

[chrisdembia]

• What about having separate tabs/panes for Properties, Connectors, Inputs, and Outputs?
• Then, the title for this widget could be "Attributes" instead of "Properties"
• What about using full path names in the dropdown for connecting Connectors?
• It'd be great if the Navigation pane allowed typing in text and filtering by name/type (basically, searching through the available components).

[aymanhab]

Thanks @chrisdembia for starting this discussion.

As far as I can tell the only component that has inputs (until recently) is the reporter written for the hackathon, if these become common, and can be discovered then sure we can show them too.

My thinking was that you need outputs only when wiring a reporter and properties + connectors when model building/editing so it's good to keep together but if that's not the common workflow, then sure we can arrange as needed (also both properties and connectors are editable, while outputs aren't)

• Full path names is reasonable but introduces a tradeoff that we need to balance, otherwise a tree of few levels of path names would clutter the GUI (imagine the names of coordinates in menus, drop-downs and coordinate-viewer etc. that are 50+ characters long) We can discuss options.
• There's a search functionality I think but I need to find out how to enable it.

[chrisdembia]

I'm creating a "muscle metabolics calculator" that has inputs, and these inputs are wired as part of model building. Though I think it's fine if the GUI waits until inputs are more common before trying to support them.

The hope is that future component names would be shorter, so that full path names won't be so onerous (e.g., knee_r/flexion/value instead of knee_r/knee_angle_r/value).

[chrisdembia]

Good points about separating outputs, since they are not editable.

[aymanhab]

Perfect, let me know when you have your calculator so I can test traversing and displaying Inputs.