-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move parameter ports to top of the box #469
Comments
Would need to define "parameters" versus "inputs" in the FBP protocol, to communicate it from runtime to UI. |
The biggest design challenge with this proposal is where to put the labels. I agree that visually denoting params would be good. Another concept: |
Right, and if we treat inports as parameter ports as soon as one sets a static value, it might be confusing if the ports move around. Can we do this for components that use wirepattern? I agree with forresto that top and bottom ports wold be hard to label. Just moving stream ports up and having a gap to the other port would be nice already. |
I think the parameter ports should be indicated by port colo/shape rather than their position. Position influences heavily the routing of edges, and should be free to move around for this purpose. @forresto we used to move ports around based on the direction of their edges. Why did we stop doing that? |
@jonnor there are things like r/g/b or x/y/z where I think it is confusing if they swap their order. |
Fair point. For quick visual recognition (pattern matching) having the order the same is also beneficial. |
I made that call for quick visual recognition when we switched from custom elements to svg/zui. |
One thing to double-check is that ports should always be ordered as authored. |
We have two types of input ports: inputs that are used in processing, and parameters that configure the behavior of the component but don't actually cause it to execute. For an example, see how NoFlo's WirePattern is configured
Currently both types are rendered to the left of the node in the graph:
Moving the params to the top of the box, like in IDEF0 would help to clarify the differences between these port types.
The text was updated successfully, but these errors were encountered: