Welcome to yEd Q&A!
Here you can ask questions and receive answers from other members of the community and yEd developers. And you can tell us your most wanted feature requests.

Categories

Better neighborhood/successors/predecessors view

+4 votes

For work with a large graphs is a great helper the neighborhood view and its Convert to Document function. To be even more useful please support the following:

  • display the connections between the selected nodes (the partial workaround is to select the edges of the selected nodes) - I read that this is a feature to not display the edges between selected nodes - why??? - do it at least configurable.
  • do not limit the number of elements (or adjustable limit)
  • allow to set the depth of neighbors (not just the 1st level)
in Feature Requests by (370 points)
Re  "I read that this is a feature to not display the edges between selected nodes - why???":

The context views are all about reducing the number of displayed elements (with the purpose of a) gaining insight into graph structure and b) achieving nice arrangements).
In the case of the neighborhood of selected nodes, the set of included edges is consistent with the definition of shortest paths.
Lets try to look to problem from different point of view. In this view a missing edge is not consistent with a definition of shortest path, the path is corrupted due to missing edge.
The requested feature is about to be able easily extract a portion of graph based on the selected nodes including all of their negihbors optionally  recursively until the defined depth. In this point of view a missing edge to neighbor (regardless if the neighbor is also selected or not) is a bug.
There seems to be a misunderstanding here. My comment was not meant as an response to your feature request in general, but solely meant as an answer to your "why" question.
Of course, there are ways to build neighborhood views other than the one we have chosen. (Case in point, the one you suggest in your original post.) And, of course, it makes sense to request different behaviors. Actually, we do appreciate such suggestions and feature requests very much.

However, that does not mean the current behavior is broken. Indeed, "In this view a missing edge is not consistent with a definition of shortest path, the path is corrupted due to missing edge." is just plain wrong. Solutions for *destination* shortest-path problems never contain edges between source nodes. Moreover, the statement "In this point of view a missing edge to neighbor (regardless if the neighbor is also selected or not) is a bug." is just not applicable, because the behavior you would like to have is not the behavior that is currently implemented.

Again, I am not saying your request is not valid. All I am saying is that the current behavior is correct with regards to the specification that was originally decided on.
I would like to reopen the issue. As I understood - it is about following:
http://s13.postimg.org/y9dteb9lz/yed_neighbor.png
When I choose several nodes, there is no connection shown in neighborhood view. Expected to see the connection. Or how could I show simplified subgraph with all connections of first level? Thank you!

1 Answer

0 votes

The second feature request

  • do not limit the number of elements (or adjustable limit)

is available as of yEd 3.14. See also Context View Limitations for High Edge Density Nodes.

by [yWorks] (160k points)
Legal Disclosure | Privacy Policy
...