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

Make it clear which nodes have incoming connections and which nodes have outgoing connections when you have a node selected #875

Closed
tomwilkie opened this issue Jan 29, 2016 · 14 comments
Assignees
Labels
component/ui Predominantly a front-end issue; most/all of the work can be completed by a f/e developer feature Indicates that issue is related to new end user functionality needs-design UI representation/flow requires a fair amount of thought
Milestone

Comments

@tomwilkie
Copy link
Contributor

Something like this (when viewing the detail panel):

screen shot 2016-01-28 at 17 11 10

I think this will make it super obvious what containers / process etc something is talking to, and what container / process is talking to it.

@tomwilkie tomwilkie added the component/ui Predominantly a front-end issue; most/all of the work can be completed by a f/e developer label Jan 29, 2016
@tomwilkie
Copy link
Contributor Author

If you combine this with some kind of semantic colouring, this might be interesting way to answer the question "why is this container sick".

What do you think @davkal @foot @paulbellamy?

@paulbellamy
Copy link
Contributor

I would be more in favour of this if "incoming" vs "outgoing" was more than a guess, but even determining what that means is tricky.

@tomwilkie
Copy link
Contributor Author

conntrack'd connections have direction: #539

@davkal
Copy link
Contributor

davkal commented Feb 4, 2016

I like it, though arrow offset will have to be calculated differently for all new shapes.

@tomwilkie
Copy link
Contributor Author

This also came up with Darren from Rancher.

@paulbellamy
Copy link
Contributor

conntrack'd connections have direction: #539

But most connections are not conntrack'd (only short-lived ones are), no?

@tomwilkie
Copy link
Contributor Author

Actually almost all connections are conntracked, the set of ones detected
by proc spy and not by conntrack is almost nil.

On Monday, 15 February 2016, Paul Bellamy notifications@github.com wrote:

conntrack'd connections have direction: #539
#539

But most connections are not conntrack'd (only short-lived ones are), no?


Reply to this email directly or view it on GitHub
#875 (comment).

@tomwilkie
Copy link
Contributor Author

Edge direction is now even more meaningful: we get them from conntrack. @davkal do you think this is something we could have a go at (even without arrow heads)?

@pidster
Copy link
Contributor

pidster commented Mar 2, 2016

+1 for adding a visual indicator for direction, to edges. #872

@rade
Copy link
Member

rade commented Jul 4, 2016

How is this different from #872?

@rade rade added the feature Indicates that issue is related to new end user functionality label Jul 4, 2016
@tomwilkie
Copy link
Contributor Author

How is this different from #872?

This is talking about the "selected" mode, where as #872 is in the general canvas.

Also this suggestion is about changing the location of the nodes (incoming at the top, outgoing at the bottom) when you select a node, whereas #872 is just about adding a direction indicator for edges on canvas.

@bowenli bowenli added the needs-design UI representation/flow requires a fair amount of thought label Nov 10, 2016
@rade
Copy link
Member

rade commented Jan 11, 2017

Also this suggestion is about changing the location of the nodes (incoming at the top, outgoing at the bottom) when you select a node

I like that, and it's something that could be done independently from tackling the thorny/controversial issue of adding arrow heads.

@rade rade modified the milestone: Backlog Jan 11, 2017
@jpellizzari jpellizzari self-assigned this Feb 22, 2017
@jpellizzari
Copy link
Contributor

Related to #1636

@jpellizzari
Copy link
Contributor

This is mostly accomplished by #2317. Concepts involving re-arranging the nodes were unsuccessful, as it lead to very unbalanced "sides" of the diagram which lead to difficult to read diagrams. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/ui Predominantly a front-end issue; most/all of the work can be completed by a f/e developer feature Indicates that issue is related to new end user functionality needs-design UI representation/flow requires a fair amount of thought
Projects
None yet
Development

No branches or pull requests

7 participants