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

export DOT #6

Merged
merged 3 commits into from Mar 9, 2019

Conversation

Projects
None yet
3 participants
@brandly
Copy link
Contributor

brandly commented Mar 4, 2019

i thought using a data URL would be a good way to handle it. i imported elm/core and exported this file.

is there a better way than this to get the graph?

maybe calculating the URL on every render is inefficient. let me know what you think!

screen shot 2019-03-03 at 7 42 45 pm

@brandly

This comment has been minimized.

Copy link
Contributor Author

brandly commented Mar 4, 2019

maybe there are more attributes we'd want to export into DOT. i didn't notice outputWithStylesAndAttributes til now, but that's probably what we should use.

maybe someone like @jschomay who's more familiar with DOT knows what attributes we should export. here are the vertices and edges we're working with.

EDIT: we could also use downloadAs, allowing us to specify a file name instead of just opening in a new tab.

@brandly brandly referenced this pull request Mar 4, 2019

Open

Import feature? #4

@jschomay

This comment has been minimized.

Copy link

jschomay commented Mar 8, 2019

Hi Bradly,

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.

@jschomay

This comment has been minimized.

Copy link

jschomay commented Mar 8, 2019

For what it's worth, here is a graph that I would like to be able to import/export into Kite. You can see a number of unusual attributes in play.

image

@brandly

This comment has been minimized.

Copy link
Contributor Author

brandly commented Mar 8, 2019

thanks for the thorough response!

Graph appears to always export a digraph. potentially Kite's dependence on it is a limiting factor in all this, but i really don't know much about Graph still!

i think this function will allows us to export arbitrary graph/node/edge properties, but i'm not sure certain concepts, like arrowhead/arrowtail, exist within Kite. i think the main priority for this PR is defining the best mapping between existing Kite properties and graphviz attributes.

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.

the VertexProperties and EdgeProperties both exist as defaults, which i think would be like root level properties, but also exist on a per vertex/edge basis. i guess these bagProperties would be like subgraph properties, but it doesn't look like Graph.DOT supports exporting subgraphs.

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

@erkal

This comment has been minimized.

Copy link
Owner

erkal commented Mar 9, 2019

Hey, sorry for responding so late. I had accidentaly "unwatched" Kite's repo.
I will merge this PR just now.

Currently Kite is using local storage to save graphs. Graphs are encoded as .json string. After @brandly wrote the parser for .DOT files, I started to think that maybe .DOT is the format I should use instead of .json.
And Kite actually shouldn't be using the local storage because it is limited to 5 MB. So, the save button should export a .DOT file. The user can have his/her graphs in his computer, all saved as .DOT files.

I would first write two converters:

  1. f : GraphFile -> Dot
  2. g : Dot -> GraphFile

such that g (f graphFile) always equals graphFile.

Some comments :

maybe there are more attributes we'd want to export into DOT. i didn't notice outputWithStylesAndAttributes til now, but that's probably what we should use.

I agree.

EDIT: we could also use downloadAs, allowing us to specify a file name instead of just opening in a new tab.

I think this is better.

Are "bags" subgraphs?

No, they are sets of vertices. They don't store edges.

Graph appears to always export a digraph. potentially Kite's dependence on it is a limiting factor in all this, but i really don't know much about Graph still!

Actually it is not a limiting factor. My plan for Kite is to add a undirected: Bool field to the EdgeProperties and otherwise make no distinction about graphs and digraphs.

i think it's worth opening separate issues for any properties you think would be useful, like node shape.

Yes

@erkal erkal merged commit 52456da into erkal:master Mar 9, 2019

@erkal

This comment has been minimized.

Copy link
Owner

erkal commented Mar 9, 2019

I think using File.Download.string would be better than downloadAs.

@brandly brandly deleted the brandly:export-dot branch Mar 11, 2019

@brandly

This comment has been minimized.

Copy link
Contributor Author

brandly commented Mar 12, 2019

I had accidentally "unwatched" Kite's repo.

😂

And Kite actually shouldn't be using the local storage because it is limited to 5 MB.

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.

I would first write two converters:

this is interesting! i like this path forward. since GraphFile is specific to Kite, we would define these converters within Kite itself.

i think this also means i need a DOT -> String, since our current Graph -> String exporting wouldn't maintain the g (f graphFile) == graphFile constraint. correct me if i'm wrong!

Are "bags" subgraphs?

No, they are sets of vertices. They don't store edges.

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 g (f graphFile) == graphFile, but i'm not sure what would happen when you import an arbitrary DOT file that wasn't generated by Kite.

Actually it is not a limiting factor. My plan for Kite is to add a undirected: Bool field to the EdgeProperties and otherwise make no distinction about graphs and digraphs.

this is great! it still appears that Graph.DOT.output exports a digraph no matter what. if i add a DOT -> String to DotLang, we won't have that limitation.

--

i think we're on a good path. i'll define DOT -> String soon and get DotLang published to the package manager.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.