Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
export DOT #6
maybe there are more attributes we'd want to export into DOT. i didn't notice
EDIT: we could also use
My comments may be out of scope for this PR, but I I'll give you my thoughts on encode/decoding attributes since you asked.
I've used many DOT attributes, but I'm by no means an expert. In the original graph package I had first thought of setting up a default record just as you have, but I didn't want to go through the trouble of representing all possible attributes, so I opted for an untyped string-based approach.
I do like the default record, and the included properties seem good. The only one I didn't see that I've used before is the node shape. There are probably others, and they may need to be added on a case by case basis by request. Alternatively, there may be a way to make it extensible on use, such as setting it up as an extensible record, though this would change the whole api to be parametric.
Are "bags" subgraphs? If so, I think they have the main attributes.
The only other thing that I don't see are graph properties, which may be useful to add. I'm sure you've seen it, but here are all properties for graph/node/edge https://graphviz.gitlab.io/_pages/doc/info/attrs.html#d:rankdir.
One last question - do I understand correctly that these are graph-level defaults? I often will add node/edge attributes per node/edge rather than at the root level, so you'd want to be sure to be able to encode/decode those as well.
Like I said, all of this is probably out of scope for this PR. In fact, I think the encoders and decoders and corresponding attribute types should be a part of the elm-community/graph package, rather than a concern here. I hope that helps answer your question to some extend.
thanks for the thorough response!
i think this function will allows us to export arbitrary graph/node/edge properties, but i'm not sure certain concepts, like
i came across this link you mentioned yesterday, and started to get a sense of what attributes graphviz cares about, but actually defining this mapping would be a fair amount of work for me, since i'm only loosely familiar with both Kite and graphviz. if you're interested in helping with this, let me know!
once a DOT importer exists, i think there would be a loss of certain attributes after passing that DOT file you provided thru an importer and then this exporter, but maybe once we get over those initial hurdles, we can chat with @erkal and consider adding more properties to Kite. i think it's worth opening separate issues for any properties you think would be useful, like node shape.
thanks again for discussing
Hey, sorry for responding so late. I had accidentaly "unwatched" Kite's repo.
Currently Kite is using local storage to save graphs. Graphs are encoded as
I would first write two converters:
Some comments :
I think this is better.
No, they are sets of vertices. They don't store edges.
Actually it is not a limiting factor. My plan for Kite is to add a
i think 5 MB could hold quite a few graphs. i vote that we continue to use local storage for its convenience but encourage exporting to a more permanent file.
this is interesting! i like this path forward. since
i think this also means i need a
would we still want to define a "subgraph" in DOT that just lists the vertices in the bag? i think we need to do something like that to maintain
this is great! it still appears that
i think we're on a good path. i'll define
completely using DOT, instead of JSON, is probably a fair amount of work. maybe we can break it up into actionable steps and lay it out on the roadmap.
thanks again for discussing, everyone.