Import feature?
jschomay opened this issue · comments
Very cool tool! I've been using online graphviz projects like https://dreampuf.github.io/ for many uses, but I would like more interactivity, such as what you provide.
I saw a plan for exporting different formats, but how about import DOT format? Or at least have a DOT editor. I find it easier to create graphs (especially when I want to specify labels/colors/etc) that way. Also, most graph libraries can export to different formats such as DOT (this is true for the elm graph library too - I'm the one who originally added it!).
Thanks for considering this feature, and great work!
Thank you for the nice words.
Kite uses elm-community/graph. So thank you for contributing to that package!
You could place a "DOT file import/export window" just below the "Elm Module Dependency import window":
I would merge it if you would make a pull request.
Otherwise, I can do it myself (but it can take time because I don't have so much time for Kite right now).
It looks like we need a parser for the DOT Language.
It makes then sense to do it as an independent elm package and publish it.
i wrote a DOT parser.
it has a few TODOs still. i think the main issue is it can't parse HTML nodes, and it can't handle arbitrarily placed comments. i looked at this package for html parsing, but it only exposes the run function and i think i want this internal node definition.
i've never written a serious parser in Elm, so maybe @jinjor or someone could look it over.
Great!
The biggest thing was writing the parser. :)
I cannot comment on the parser because I also have never written a serious parser. But I am sure that it is good.
thanks to @hecrj, i think the parser is thoroughly implemented now! i plan to do more testing and write some comments/docs, but we should be able to move forward on this feature soon.
🎉I don't know much about parsers but the code looks very clean and nice.
I am not going to be able to work on this for a while. Of course, if you make a pull request, I will merge.
I never used elm/file but it looks like the library to use. Or maybe just a text field?
here's what i'm thinking:
- we need
Dot -> Graphfor importing - we need
Graph -> DotandDot -> Stringfor exporting. toString : Dot -> Stringcan be part of my repo. i'm not sure where theDot/Graphconverters should live.elm/filewould be good to integrate. a<textarea>might also be nice, for those who are familiar with DOT and can write it by hand. thetextareais easier to implement, so we could start there.
does that all sound right?
i see this Graph -> String, which means exporting to a DOT file already seems possible. (#6)
my repo could also have a DOT -> String, since i'm under the impression DOT can represent more visually than Graph. this wouldn't be a priority for Kite tho.
@sgraf812 are you interested in graph having a DOT -> Graph converter? Graph feels more fundamental to me, and i don't have much sense of how likely you would need DOT if you're using Graph. i'm happy for it to live in my repo, but i'm not sure what's best!!
Hey, sorry to be so late to the discussion. I'm generally a little sceptical of adding any more importing/exporting functionality and think they should rather go in seperate packages. Things aren't so bad when it's just some hacky Graph -> String conversion, but depending on a package that defines the Dot language and a parser just doesn't feel right to me.
So: I'd be happy to see a function Graph -> DOT and DOT -> Graph and would deprecate the hacky Graph.DOT module in favor of it, but not as part of elm-community/graph.
not as part of elm-community/graph
If this functionality ends up in a separate package, I'd prefer it to be stand-alone (as opposed to a part of kite), so that I can use it along side of elm-community/graph. I definitely have projects that use Graph that won't need kite that will need DOT -> Graph.
there's some discussion here where it looks like we'll be going between GraphFile and DOT, not just Graph, for Kite's purposes.
So: I'd be happy to see a function Graph -> DOT and DOT -> Graph and would deprecate the hacky Graph.DOT module in favor of it, but not as part of elm-community/graph.
I definitely have projects that use Graph that won't need kite that will need DOT -> Graph.
i agree. this should exist. i'm not sure where it'll live.
i haven't published DotLang at all yet, but it's almost ready. once that happens, we'll probably write GraphFile -> DOT first. since GraphFile has a Graph within it, we'll basically have a Graph -> DOT implementation, which we could then pull out of Kite into a separate package.
i'm glad that there's wider interest in these components!
i haven't published DotLang at all yet, but it's almost ready. once that happens, we'll probably write GraphFile -> DOT first. since GraphFile has a Graph within it, we'll basically have a Graph -> DOT implementation, which we could then pull out of Kite into a separate package.
After you publish DotLang, I can write GraphFile -> DOT and DOT -> GraphFile.
I will try to do it in such a way, that the field names coincide with the property names that are used by GraphViz. So that, if one wants to transport his/her graph from Kite to Graphviz, this would be helpful.
thanks @erkal! i should have time to write out more docs and get it published soon.
i'll try to get an initial version out before writing DOT -> String, so we can build an importer. having you write DOT -> GraphFile will be a good exercise in seeing if DOT's current implementation has any shortcomings. plus, i'm just excited to see someone else use it 😄
after we see how that goes, i can add DOT -> String, and we should be able to build a nice exporter as well.
@erkal i published DotLang! i'm sure the docs aren't ideal yet, and maybe the AST itself could be improved. please send me any suggestions you have.
i already added DOT -> String, so theoretically, we have everything we need to import/export DOT and to use DOT, instead of JSON, for graph serialization.
looking forward to seeing this come together!
Great! ❤️
The docs are ideal to me.
I will do the Kite side as soon as I find time.
Ok, now it is in progress
i see that toDot and fromDot are both checked off! are you working from a branch i could see?
I checked those boxes maybe too early. :) But I am going to push something in a couple of days. I will send you a message when I do.
Hey @brandly, I pushed a branch: using-dotlang
It is not working yet, partly because of the issues I opened in brandly/elm-dot-lang/issues.
So we made good progress 🎉
I think we are done with the 99% of code if we restrict ourselves to the use of dot language inside Kite.
For importing .dot files that aren't exported by Kite, I think there is a lot of work to do. And also I see that there is no end to it: https://www.graphviz.org/doc/info/attrs.html
But we can extend in time, starting with the ones that are most used.
idea: since there will undoubtedly be graphviz properties that aren't first-class properties in Kite, we could hold these extraneous properties in a Dict String String. that way, we should be able to import a .dot file and then export an equivalent .dot, without losing those properties.
i haven't looked at how feasible this is at an implementation level. maybe it complicates things more than it's worth.
We already have fromDot(toDot(g)) for all g : GraphFile.
It is a good idea to have: toDot(fromDot(d)) = d for all d : Dot.
But only a Dict String String may not be a good fit to keep all the other things like subgraphs that Kite does not read.
How about keeping a field: dotFile : Dot in GraphFile and rewrite toDot in such a way, that it updates thid field?
Ok, the local storage uses now DotLang instead of json.
One can also export and import graphs as Dot files.
I am closing this issue.
I am going to open a new issue for the last problem above.