export to RDF/PDF/SVG/ formats

[danionita]

Export/import menu-items are not responding.

[bobismijnnaam]

Implemented export for images (bmp, jpeg, png, gif). Think we should implement PDF as well I think (should be doable, saw a code sample float around somewhere). RDF prints to stdout at the moment, JSON is not implemented at all atm (still think we should switch before 1.0). Importing RDF/XSVG, I think we want that at some point as well, but afaik it's not a priority...?

[danionita]

RDF should then be easy, and is also important. But how about RDF import? Pdf would be nice to have if easy. Otherwise, vector graphics would be more useful. Do you mean JSON for saving .e3 files? What is is now? XML or the hacky way you mentioned a few weeks back?

On 7 Aug 2016 15:12, "Bob Rubbens" notifications@github.com wrote:

Implemented export for images (bmp, jpeg, png, gif). Think we should implement PDF as well I think (should be doable, saw a code sample float around somewhere). RDF prints to stdout at the moment, JSON is not implemented at all atm (still think we should switch before 1.0). Importing RDF/XSVG, I think we want that at some point as well, but afaik it's not a priority...?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/danionita/e3tools/issues/39#issuecomment-238081694, or mute the thread https://github.com/notifications/unsubscribe-auth/AKjEpBnsOWFVe0BRoTVV32qQVe44pr09ks5qddnYgaJpZM4Jcja8 .

[bobismijnnaam]

It's trivial to export rdf to a file now (since it only involves asking the user where to save it). Importing RDF is doable as well, but of course the user will get a messy result (actors overlapping et al.). Pdf shouldn't be too hard, but if it turns out to be hard I think we should skip it. I'll have to look into vector graphics, no clue how that would work atm.

Yeah. Right now, to store our models, we're basically first serializing the whole model into an xml file, and then storing that file in a zip (together with a json file for configuration settings, name, value objects, etc.). However that xml file is heavily dependent on the structure of the editor application. If we rename a field, move a package, or change a type, it is almost certain that all saved files break. So you either have to recreate models after such a "breaking change" or you'd have to create a converter (ugh).

I think before we hit 1.0 or something similar we should switch to some (inner?) format that doesn't depend on the structure of the java application. Otherwise you cannot change anything in the application without first considering if the user's save files will be fine. However we should probably discuss that face to face sometime. It's a pretty involved subject I think, hehe.

On 8 August 2016 at 12:39, danionita notifications@github.com wrote:

RDF should then be easy, and is also important. But how about RDF import? Pdf would be nice to have if easy. Otherwise, vector graphics would be more useful. Do you mean JSON for saving .e3 files? What is is now? XML or the hacky way you mentioned a few weeks back?

On 7 Aug 2016 15:12, "Bob Rubbens" notifications@github.com wrote:

Implemented export for images (bmp, jpeg, png, gif). Think we should implement PDF as well I think (should be doable, saw a code sample float around somewhere). RDF prints to stdout at the moment, JSON is not implemented at all atm (still think we should switch before 1.0). Importing RDF/XSVG, I think we want that at some point as well, but afaik it's not a priority...?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/danionita/e3tools/issues/39#issuecomment-238081694, or mute the thread https://github.com/notifications/unsubscribe-auth/ AKjEpBnsOWFVe0BRoTVV32qQVe44pr09ks5qddnYgaJpZM4Jcja8 .

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/danionita/e3tools/issues/39#issuecomment-238200962, or mute the thread https://github.com/notifications/unsubscribe-auth/AC8IaISxvy-jkjCUSmwa-aJiMmaJXmF6ks5qdwdzgaJpZM4Jcja8 .

[danionita]

Sure, let's discuss this when you're back. I am only here until the 18th so it will be tight. This also might explain why older e3 files don't open correctly anymore..

On Aug 8, 2016 1:12 PM, "Bob Rubbens" notifications@github.com wrote:

It's trivial to export rdf to a file now (since it only involves asking the user where to save it). Importing RDF is doable as well, but of course the user will get a messy result (actors overlapping et al.). Pdf shouldn't be too hard, but if it turns out to be hard I think we should skip it. I'll have to look into vector graphics, no clue how that would work atm.

Yeah. Right now, to store our models, we're basically first serializing the whole model into an xml file, and then storing that file in a zip (together with a json file for configuration settings, name, value objects, etc.). However that xml file is heavily dependent on the structure of the editor application. If we rename a field, move a package, or change a type, it is almost certain that all saved files break. So you either have to recreate models after such a "breaking change" or you'd have to create a converter (ugh).

I think before we hit 1.0 or something similar we should switch to some (inner?) format that doesn't depend on the structure of the java application. Otherwise you cannot change anything in the application without first considering if the user's save files will be fine. However we should probably discuss that face to face sometime. It's a pretty involved subject I think, hehe.

On 8 August 2016 at 12:39, danionita notifications@github.com wrote:

RDF should then be easy, and is also important. But how about RDF import? Pdf would be nice to have if easy. Otherwise, vector graphics would be more useful. Do you mean JSON for saving .e3 files? What is is now? XML or the hacky way you mentioned a few weeks back?

On 7 Aug 2016 15:12, "Bob Rubbens" notifications@github.com wrote:

Implemented export for images (bmp, jpeg, png, gif). Think we should implement PDF as well I think (should be doable, saw a code sample float around somewhere). RDF prints to stdout at the moment, JSON is not implemented at all atm (still think we should switch before 1.0). Importing RDF/XSVG, I think we want that at some point as well, but afaik it's not a priority...?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/danionita/e3tools/issues/39#issuecomment-238081694 , or mute the thread https://github.com/notifications/unsubscribe-auth/ AKjEpBnsOWFVe0BRoTVV32qQVe44pr09ks5qddnYgaJpZM4Jcja8 .

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/danionita/e3tools/issues/39#issuecomment-238200962, or mute the thread https://github.com/notifications/unsubscribe-auth/AC8IaISxvy-jkjCUSmwa- aJiMmaJXmF6ks5qdwdzgaJpZM4Jcja8 .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/danionita/e3tools/issues/39#issuecomment-238206942, or mute the thread https://github.com/notifications/unsubscribe-auth/AKjEpHr1ZOxNocFNaZW54992ceDIS4boks5qdw8vgaJpZM4Jcja8 .

[bobismijnnaam]

Alright, RDF export works as of ecee2e5f7a0308a71559ddf7892f997a4ed56712. Seems like PDF support was dropped by mxGraph (altough I can't find a source that states clearly whether JGraphX does or does not support it). SVG support is limited (see image).

We could consider a "simpler" style for the svg export (just more appropriately colored rectangles). Either that, or I have to extend the SVG implementation of JGraphX, which might take a while.

RDF import is doable but might be hard, and will result in a mess (probably, the auto layout of mxGraph doesn't handle everything perfectly) of actors that the user will have to sort out.