No EMF and some other major refactoring

[ergouser]

I don't know the level of interest in this, but there's a branch here (that is definitely a work in progress, so may change, possibly a lot) https://github.com/ergouser/graph-editor/tree/noemfnoloc that remove the EMF dependency and move design parameters to the skins.

The reasons for removing EMF are here https://github.com/ergouser/graph-editor/blob/noemfnoloc/WHYREMOVEEMF.md

A GNode is a concept with no location, width or height. The Skin introduces the graphical representation and in principle you could have multiple graphical representation - multiple skins - representing the same GNode. X,Y, Width and Height are logically not attributes of the GNode. The notes on this are here: https://github.com/ergouser/graph-editor/blob/noemfnoloc/WHYMOVEDIMENSIONSTOSKINS.md

In our use case we already have a (very large) collection of objects that we want to add to the model as GNodes. We build a graph of GNodes and then deploy the graph without the view. Only the Model interface (GNode, GModel, GConnector, GConnection) are required at runtime (no EMF and those interface also don't reference JFX).

[eckig]

I saw the work on your fork a while ago. It is interesting but quite a different approach.

We rely quite heavily on batch processing (and merging) of EMF Commands which allows the use of a separate domain model for storing the custom data. So I do not see us moving to this approach in the near future.

[ergouser]

I feel that moving an existing project would be quite a challenge. You'd have to have some clear benefit from the alternate approach (primarily, I would expect, the idea of development time and runtime)

The same architecture exists for Commands post EMF. There's a CommandStack class and you can have multiple of those (similar to Domains) and these can have Commands and Compound Commands along with undo/redo. In our case we (currently, may change) have multiple Models, imagine one per window, but in reality our windows are pairs and so one CommandStack (with unique undo/redo) per Model.

More broadly, fundamentally, the architecture is largely unchanged, the reason to adopt the project is that the architecture is good. The change does make Skins an essential, first class component, in the architecture. In our case we expect users to change the attributes of the skins (think color, etc.) and need to save those anyway. There are likely still to be some changes here to allow more flexible node/skin mapping. I'm still trying to figure out the minimap.

Connectors are attributes of the Nodes, not the model (you can't add a Connector without a Node). Joints are attributes of the Connection. (Joints are problematic because they are exclusively a graphical affectation and have no basis in the Model). Connections between Models are still an issue for us. Connections are actually attributes of Connectors, but since they are an attribute of two Connectors there's no clear home for them. They're currently still in the Model, but what happens if the Connection is between two models? And then the Connection needs two skins - one for each Model representation.

It was a great cleansing to remove the many conversions involved in supporting EMF replacing those with JFX listeners. Since the model structure is not dynamic, the benefits of EMF are reduced and EMF was mostly a notification framework. JFX does that well and without constant type-conversions.

The removal of the graphical attributes from the node to the skins, arguably a much large change, but allows any POJO to implement an interface and play in the environment.

We'll be working to fix/re-implement the tests but the demo code works, to my knowledge, about as it ever did.