Skip to content
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

Open
bergie opened this issue Apr 2, 2015 · 8 comments
Open

Move parameter ports to top of the box #469

bergie opened this issue Apr 2, 2015 · 8 comments

Comments

@bergie
Copy link
Member

bergie commented Apr 2, 2015

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:

screenshot 2015-04-02 at 17 20 52

Moving the params to the top of the box, like in IDEF0 would help to clarify the differences between these port types.

screenshot 2015-04-02 at 17 25 03

@jonnor
Copy link
Member

jonnor commented Apr 2, 2015

Would need to define "parameters" versus "inputs" in the FBP protocol, to communicate it from runtime to UI.

@forresto
Copy link
Member

forresto commented Apr 3, 2015

The biggest design challenge with this proposal is where to put the labels.

I agree that visually denoting params would be good. Another concept:

input and options

flowhub/the-graph#197

@ensonic
Copy link
Contributor

ensonic commented May 7, 2015

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.

@jonnor
Copy link
Member

jonnor commented May 7, 2015

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?

@ensonic
Copy link
Contributor

ensonic commented May 7, 2015

@jonnor there are things like r/g/b or x/y/z where I think it is confusing if they swap their order.

@jonnor
Copy link
Member

jonnor commented May 7, 2015

Fair point. For quick visual recognition (pattern matching) having the order the same is also beneficial.

@forresto
Copy link
Member

forresto commented May 7, 2015

I made that call for quick visual recognition when we switched from custom elements to svg/zui.

@forresto
Copy link
Member

forresto commented May 7, 2015

One thing to double-check is that ports should always be ordered as authored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants