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

Suppress weight labels from rendering #17

Closed
wants to merge 1 commit into from

Conversation

cyberscribe
Copy link

Adds a extensible options array to accomplish this.

@clue
Copy link
Member

clue commented Jul 13, 2016

Thanks for your PR, much appreciated 👍

I think having this feature makes perfect sense, but I have to admit I'm not a big fan of the current implementation.

The related code autogenerates an edge label. I think it makes more sense to split this code off and possibly pass a custom instance into the dot exporter.

See also graphp/graph#114 and #14.

@cyberscribe
Copy link
Author

Feel free to re-implement. I just needed a quick way to turn off those annoying labels in dot. Merge or discard--up to you.

@clue
Copy link
Member

clue commented Jul 14, 2016

Didn't mean to discourage your contribution, this PR is much appreciated 👍

I think it makes perfect sense to omit the weight in certain cases. And it probably also makes sense to omit the other edges attributes (flow and capacity) in similar cases.

What do you think about this?

@cyberscribe
Copy link
Author

I agree. This was the intent of implementing a simple associative array so that you can extend it into any number of "toggle switch" options.

If you don't like the direct access within the class, we could implement a getOption() method that checks if it's set (false if not) and returns the value. We could then wrap all conditional output in a getOption() call beforehand, and give a list of valid options for use.

@clue
Copy link
Member

clue commented Jul 14, 2016

I'm not sure this is going to be sufficient once graphp/graph#114 has been implemented.

This would mean we would have to specify which attributes get exported which way. This is certainly beyond our control for special attributes, so I think it makes more sense to provide a simple "export mathematical properties like previously"-implementation and a "do not export anything"-implementation and an interface for custom implementations.

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

Successfully merging this pull request may close these issues.

2 participants