Eclipse Community Forums: GMF (Graphical Modeling Framework)

Help

Home

Home » Modeling » GMF (Graphical Modeling Framework) » Moving GMF-independent code to GEF?

Show: Today's Messages :: Show Polls :: Message Navigator

Moving GMF-independent code to GEF? [message #891546]

Mon, 25 June 2012 08:17

Yoann Rodiere

Messages: 3
Registered: October 2011

Junior Member

Hi all,

I heard on June 13th at the Eclipse Democamp Grenoble (France) that some portions of the GMF code which rely only on GEF might be moved to GEF in the future, if it proved useful. And I'd like to say that there is people which might benefit from this. Because, yes, there's still some people using raw GEF Wink

We -- at Eclipse SOA JWT -- just tried to implement SVG export for our (GEF) diagrams, and we finally decided to copy your very useful utilities in our project to do so. This includes in particular the "org.eclipse.gmf.runtime.draw2d.ui.render.awt.internal.svg.export.GraphicsSVG" and "org.eclipse.gmf.runtime.draw2d.ui.render.awt.internal.graphics.GraphicsToGraphics2DAdaptor" classes. As Mickaël Istria and Aurélien Pupier saw when we met, that was our "less bad" solution at the moment: the core of these utilities is more or less GMF-independent, but unfortunately the public API to use them is not. Obviously we kept the copyright notices and released everything under the same EPL license. For the record, the corresponding bug report is #327563.

So here are my two cents: if you can contribute these classes to the GEF project, this could benefit to people using it (at least to JWT Wink

). Regarding the workload, all I can say is that I spent approximately 2 days studying the code, moving it to JWT (including internal dependencies) and integrating it to our project -- keeping in mind that I am (was?) new to both Eclipse and GMF. I chose to comment out SVGImage support in SVG export, though, since we do not use this class internally.

Here is what I learned about GraphicsSVG internal dependency tree, taken from the JWT bug report. This excludes classes available in the GMF public API.

Quote:

GraphicsSVG itself (the class providing an adaptor between draw2D and Java2D
and returning a SVG dom) has 5 internal dependencies:
import org.eclipse.gmf.runtime.draw2d.ui.render.awt.internal.graphics.GraphicsToGraphics2DAdaptor;
import org.eclipse.gmf.runtime.draw2d.ui.render.awt.internal.svg.SVGColorConverter;
import org.eclipse.gmf.runtime.draw2d.ui.render.internal.DrawableRenderedImage;
import org.eclipse.gmf.runtime.draw2d.ui.render.internal.RenderingListener;
import org.eclipse.gmf.runtime.draw2d.ui.render.awt.internal.svg.SVGImage;

GraphicsToGraphics2DAdaptor, its parent class, has 2 more internal dependencies:
import org.eclipse.gmf.runtime.draw2d.ui.render.awt.internal.image.ImageConverter;
import org.eclipse.gmf.runtime.draw2d.ui.render.awt.internal.svg.metafile.GdiFont;

And SVGImage needs 5 other internal classes:
import org.eclipse.gmf.runtime.draw2d.ui.render.awt.internal.Draw2dRenderPlugin;
import eclipse.gmf.runtime.draw2d.ui.render.internal.AbstractRenderedImage;
import org.eclipse.gmf.runtime.draw2d.ui.render.internal.Draw2dRenderDebugOptions;
import org.eclipse.gmf.runtime.draw2d.ui.render.internal.Draw2dRenderStatusCodes;
import org.eclipse.gmf.runtime.draw2d.ui.render.internal.factory.RenderedImageKey;

I hope this will help taking a decision!

Report message to a moderator

Re: Moving GMF-independent code to GEF? [message #892292 is a reply to message #891546]

Wed, 27 June 2012 15:49

Mickael Istria

Messages: 865
Registered: July 2009
Location: Grenoble, France

Senior Member

Hi Yoann,

Here is an approach that could work in order to get better factorization
of all that stuff:
1. Extract and rename the necessary stuff of GMF in a plugin that only
depends on GEF, let's call it, for instance org.eclipse.gef.svg, or any
name that is more consistent with GEF conventions. Keep Copyright and
Author, add your name to Authors.
2. When you get something usable (complete and independent from GMF),
open a bug to GEF requesting support for SVG Figures. Add Aurelien as Cc
of the bug. In this bug, explain your use-case (reuse SVG out of GMF),
explain why you think it makes sense to put it in GEF, and what you did.
Attach your gef.svg plugin as a suggested implementation. IT will
probably be a new plugin if accepted in GEF, since GEF people will
probably be reluctant on adding new dependencies to Batik and so on.
3. Discuss with GEF people until they agree this is a valuable
contribution. Ask support for GMF people to +1 your request on the ticket.
4. There will probably be a complicated CQ to track IP of your
contributions. It will be more complicated since you are not the author
of all the code. The project lead and PMC should help you
5. CQ is accepted, your contribution is checked in.
6. Future release of GEF will support SVG.
7. Modify GMF to use this new GEF SVG support and contribute it.

HTH
--
Mickael Istria
JBoss, by Red Hat
My blog: http://mickaelistria.wordpress.com
My Tweets: http://twitter.com/mickaelistria

Report message to a moderator