initial draft changes for addressing lack of functionality in from_existing_graph

[cole-st-john]

In response to #4

Draft breaking changes to make the repo more functional around supporting both to and from graph usages.

• I want to include deeper testing around geometry, properties, etc both in to- and from- graph usages.
• To keep maintenance of the repo as low as possible - I want to realign all property names to match those in yEds graphml implementation - there has been substantial deviation there since the start of the project.

[deepsource-io]

Here's the code health analysis summary for commits 87125d5..c7a8c87. View details on DeepSource ↗.

Analysis Summary

Analyzer	Status	Summary	Link
Python	❌ Failure	❗ 45 occurences introduced 🎯 22 occurences resolved	View Check ↗

---

💡 If you’re a repository administrator, you can configure the quality gates from the settings.

[cole-st-john]

@ghillebrand : This is just a start at addressing #4, and it unfortunately prompts some breaking changes to make development more sustainable. But please take a look and see if this is might help.

[ghillebrand]

Hi,
At this point, I don't use many of the tag types. Certainly supporting yEds format more closely makes sense. Also, my code is very fluid at the moment, so I can adapt very easily at this point to any changes that may possibly impact me - which is unlikely.

Skimming through the commit, personally, I prefer camelCase to snake_case, so all those changes I like - but don't impact me., since I use your system in a very API-like manner!
I see you have updated the EdgeLabel handling quite a lot. Will that read in edge labels? I simply disabled saving edge names to work around it for now. I am in the middle of a mildly complex bit of code right now, but will try to pull this in sometime tomorrow and test it

I will at some point want to support higraphs, where Nodes are sets, and edges are n-ary. The nodes-as-sets seems very close to the yEd group concept, and that would quite likely suffice for nodes.
Hyperedges can start or end on edges or nodes, so and edge has a itemStartList and an itemEndList, rather than single, scalar values. And some geometrical information about where the joins all happen.

I also want to implement Hermite splines for edges, rather than Bezier, since I find the manipulation more intuitive and direct. yEd only implements Bezier (even their quad gets saved as a Bezier!) Mostly, this is a matter of the semantics assigned to control points, so it is not a huge difference.

So ultimately, I am very happy with your direction, and with any comments you may have on how to handle those things that I don't think yEd does.

Thank you for your time on this!

Grant

[ghillebrand]

@cole-st-john Hi,
I have tested this in my code, and it no longer crashes on read, but doesn't set edge.name to the value written in persist_graph.
yEd itself shows the name on reading the file.

The red-circled name in my app has been regenerated. The bottom printout shows the values generated by from_existing_graph - the key name is now present, but the value isn't pulling through.

I have added a PR #8 to put in the name parameter into your tests, which would possibly highlight this. It is how I am using it.

Thanks
Grant