| Re: [elk-dev] Meeting Minutes 2015-09-07 |
On 08/09/15 14:01, Miro Spönemann wrote: > A few thoughts: > > - We could call the core plugin org.eclipse.elk.kernel Good idea. Why didn't we think of that before? > - The source and target features of edges could refer to a common interface of ElkNode and ElkPort, e.g. ElkConnector. Then getSourceNode() would do something like > ElkConnector source = sources.get(0); > if (source instanceof ElkNode) > return (ElkNode) source; > else > return ((ElkPort) source).getNode(); > This would solve the mapping problem between nodes and ports for hyperedges. Sounds sensible. However, developers will have to be aware of the fact that even though both ports and nodes are connectors, theirs coordinates have to be interpreted differently. > - We could loosen the coordinate system convention for edges and say that their coordinate system always corresponds to their container in the EMF containment tree. We could keep the existing convention regarding which node should be the container, but also support graphs where the convention is not met (shouldn’t be a problem). By this we would gain compatibility of old .kgt files, since the containment of edges would change with the new meta model (the default container of edges is not the source, but the parent of the source). I don't see why this would result in compatibility with old .kgt files. > - Parsing properties from a persisted ElkGraph requires the layout options metadata, which is in the elk.kernel bundle. We should consider merging elk.kernel and elk.graph. Then we could more easily simplify the serialization / deserialization mechanism for ElkGraph properties. One approach: maintain a list (not a map) of key-value pairs, both strings. Additionally each such pair could have a transient field for storing the parsed value, which is loaded on demand. Whenever the value changes, it is immediately toStringed, so the list from which the serialized form is derived is always up-to-date. Advantage: no distinction between persistent and transient properties in the meta model. Disadvantage: worse runtime performance for getProperty(..) if there are many properties in the list, and possibly unnecessary toString() invocation if the graph is never serialized. > An alternative: keep the properties map transient and create another meta model that adds all the serialization-specific stuff. If you want to persist properties, use the derived meta model instead of the original. I'd be ok with merging the kernel and the graph, since the graph is such a basic component of the layout infrastructure. Changing from a map to a list doesn't seem like a good idea to me, seeing that getProperty(...) is one of the most used method calls. I think this is something we should talk about. > - Instead of pushing a standalone library to Maven Central, we could push individual bundles (those not depending on Eclipse UI). Xtext does it this way. We discussed that option, but the dependency management would have been a nightmare since it's not trivial to derive Maven-compatible dependencies from an Eclipse project's manifest file. We actually looked at how Xtext manages this. It turns out that you keep a map from Eclipse dependencies to the appropriate Maven dependencies. All in all, the process is complex enough for us to opt for the much simpler one we have settled for. Cheers, Christoph Daniel
Attachment:
signature.asc
Description: OpenPGP digital signature