| Re: [elk-dev] Some code migration details |
Do we plan to migrate klighd to ELK?
On 22.09.2015, at 15:47, Christoph Daniel Schulze <cds@xxxxxxxxxxxxxxxxxxxxxx> wrote:kgraph.text and kgraph.text.ui
We wanted these to be part of ELK (which I still think would be useful).
However, they both depend on core.krendering. Did we foresee this
problem and decide what to do about it already? Miro, you thought about
rewriting the grammar entirely. How about leaving the original
kgraph.text and kgraph.text.ui plug-ins out of ELK? This would also
allow us to keep them around in KIELER for a while for migration purposes.
Yes, let’s leave the current kgraph.text as it is so .*kgt files including rendering can still be processed. I would create a new text plugin from scratch for the ElkGraph. We should choose new file extensions anyway, since we decided to leave the old KGraph alive for easier migration of graphs. What about *.egx and *.egt?
.egx and .egt sound good. Can we extend the language in the KIELER
project to support KRendering?
Yes, but then you would have two different editors associated with *.egt: one from ELK and one from KIELER. If you open a graph that includes rendering information with the ELK text editor, you’ll get parse errors.A requirement for this is to migrate KRendering to ElkGraph. For a first version (until KLighD is completely migrated) we could also duplicate the KRendering model for the KIELER egt variant.Miro
_______________________________________________
elk-dev mailing list
elk-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/elk-dev