* setter: Name of the setter method; if null then method is not generated.

* setter: Name of the setter method; if null then method is not generated.

* callSuper: If true then generated setter will call super implementation in the end; useful when overriding methods like setBackgroundColor(Color).

* callSuper: If true then generated setter will call super implementation in the end; useful when overriding methods like setBackgroundColor(Color).

+

+

Pitfalls:

+

* Be aware of namespaces while writing XPath expressions; see [http://www.faqts.com/knowledge_base/view.phtml/aid/34022/fid/616 this] or [http://blog.davber.com/2006/09/17/xpath-with-namespaces-in-java/ this] for more details.

+

* SVGFigure does not inherit colors from it's parent figure. You must specify setBackgroundColor and setForegroundColor properties and you must set colors directly to SVGFigure.

Scenarios

Scalable/resizable figures

I have declared DiamondShape implementation as attached one and placed it
into the correct package.
In the gmfgraph.FigureGallery I have created the CustomFigure with
<figures xsi:type="gmfgraph:CustomFigure" name="PortFigure"
qualifiedClassName="org.eclipse.gmf.examples.taipan.gmf.editor.edit.parts.DiamondShape"/>

How can I start with CustomFigures

How can I use CustomLayout and what is purpose of the CustomAttribute

gmfgraph.CustomLayout is just a gate to the custom implementation of the org.eclipse.draw2d.LayoutManager class. Thus there is in fact 2 questions -- how to write draw2d Layout manager and how to plug it into the gmfgraph. This covers only the latter.

Imagine you have com.xyz.SuperLayout class in the com.xyz.misc plugin. The SuperLayout class has method setBoolParam(boolean) and public instance field int myIntParam; It also expects the instanceof superLayoutData that has setter setStringParam(String s).

In the container node create CustomLayout, set fqn = "com.xyz.SuperLayout". Note that bundleName property of CustomLayout is deprecated and not used, it does not make sense to change it.

In the just created Custom Layout create custom attribute, set name = boolParam (or BoolParam -- it doesnot make sense) -- the name is derived from setter name, value = (say) "false" or "42 / 2 >= 21".

Note that values set at the steps 4, 5 are considered opaque and just generated into the setter call or assignment statement as is. Thus, to set the string value "MG" for custom attribute StringParam you need to set value = "MG" (with quotes).

What to do with strange ClassCastException while working with (say, opening in editor, validating or generating code from) GMFGraph resource.

The most common reason of ClassCastException like the one described in the newsgroup thread is name collision in the gmfgraph resource.
GMFGraph declares the name attribute for Node's and Figure's as ID-attribute so all names used in given resource should be different.

I really want some GMFGraph notions to have the same name. Is there the way to avoid that ClassCastException?

Yes, sometimes there may be good reasons to have diffent GMFGraph notions with the same name.
After all, Compartment's name is shown at the diagram, and it may be usefull to setup different compartments for different nodes to be shown with same label.
Just define them in different resources.

There's a legacy GEF figure code and I'd like to use it with GMF

tbd (check for MapMode, etc)

I need a figure that is similar to UML package

There's no need to use custom figure, just use some GMFGraph magic...tbdTODO put link to newsgroup discussion
If you like to have custom anchor behaviour (e.g. no link attaching to package title box), you need to hand code it (there was a posting in the newsgroup).

How to create several figures at once

I.e. when creating some element, few additional should be created as well.
tbd
Need to find better place for this, as it's not gmfgraph topic

SVG

Both full and lite runtime clients may use org.eclipse.gmf.runtime.lite.svg plugin. This plugin adds dependency to Batik library and provides SVGFigure class that is a Draw2D figure that's capable of rendering SVG documents within it's bounds, in paintFigure(Graphics) method.

In gmfgraph model you could create SVGFigure element. It's recommended to create it within a figure gallery that specifies org.eclipse.gmf.runtime.lite.svg implementation bundle. You must specify documentURI property; SVG content will be taken from there. SVGFigure may contain a number of properties (SVGProperty element). Each property translates to a getter and setter methods that obtain attribute value from SVG document element or modify their values.

SVGProperty:

query: XPath query that must select org.w3c.dom.Elements.

attribute: Name of attribute that will be read or modified.

type: Type of the property; now may be String or Color.

getter: Name of the getter method; if null then method is not generated.

setter: Name of the setter method; if null then method is not generated.

callSuper: If true then generated setter will call super implementation in the end; useful when overriding methods like setBackgroundColor(Color).

Pitfalls:

Be aware of namespaces while writing XPath expressions; see this or this for more details.

SVGFigure does not inherit colors from it's parent figure. You must specify setBackgroundColor and setForegroundColor properties and you must set colors directly to SVGFigure.

Evolution of GMFGraph Metamodel

(note: this section is in need of a cleanup.)

Recently you may have noticed that something happened to the GMF Graph metamodel. All your previously created resources got a migration-prompting message. Moreover, it seemed you didn't even know how to create gmfgraphs anymore.

Firstly, most of your figures are gone, and got replaced with some odd Figure Descriptors. Well, figures are not actually gone, if you take a closer look, they are hidden inside the figure descriptor. Nevertheless, you may have a strange feeling about some other figures, which may still exist in your gallery without being wrapped by a Figure Descriptor as others did.

You may think GMF's developers minds' are in some kind of mess. However, withhold judgment for a bit and let us first demonstrate the opportunities that the changes offer moving forward. So sit back and get ready to get involved in the evolution.

First, let us get a bird’s-eye view of the main changes using the visual notation:

Before:

After:

To summarize, the changes you can observe above here, back link for ‘referencingElements’ has been removed, while the way Diagram Element references its Figure has been transformed with the help of introducing two new entities, called FigureDescriptor and ChildAccess. Obviously, some cracks did appear in their relationship, or maybe it was something awful to come between and fall them out.

Well, nothing actually tragic. We have been dreaming a long time of easing their connection as much as possible. Now the time had come to put our cards on the table. We have been thinking of pluggable Figure Galleries to be referenced from anywhere.

Consider basic.gmfgraph as an existing example you had probably seen already. As long as we had ‘referencingElements’ to list all the elements using the figure, every your usage of that pretty figure painfully affected the whole gallery. It was just as if making every new shot of a famous ancient painting would add a stroke on its canvas – horrible!

Besides, the main thing ‘referencingElements’ being used, is for discovering, whether an inner figure (nested within some other one) was referenced from somewhere, so that it would need an instance field to access it. We could not deal with such situations due to having no way to distinct element’s references for toplevel and nested figures, only the silent general ‘figure’ was all we had on the element side.

Therefore, Figure itself involved two aspects of being a diagram element’s figure: the abstract figure shape description and its physical construction description as something real, that you may touch and reference. Nowadays we have finally come to the solution, helping us to separate these design concepts. It is the Figure Descriptor, exactly.

The Figure Descriptor thing describes structure of a figure, and represents a real part of the Figure concept. Besides, it is the only thing you can reference from within your Diagram Element. You can also think of it as if Figure got a grip to handle, or even as if it was put, along with all its child content, into a basket with a firm grip called Figure Descriptor. If you were a Diagram Element yourself and had a Gallery full of Figures to use, firstly you pick up Descriptor basket at the entry to that Gallery, then slightly stroll around its shelves full of figures, choosing the prettiest one, and put it to your basket, following you way to the cash desk. :)

However, there is one more thing left unclear. The basket concept is fine, but what if I want to use some nested figure for my element. Consider, for instance, declaring Diagram Label in order to have a list of the children’ names for some Father one. Internal labels are the most common case. Then what should you put in your basket, still the Father’s toplevel one? Actually, yes. Never forget, we are GMF, and our basket is quite skillful indeed. But what can be more useful than pockets? Right, Child Accesses, as they are our advanced, named pockets. So what you need to reference child figure is wrap its toplevel container with Descriptor, and then create new Child Access within it, pointing to the desired nested shape. Finally, that is it and you are done.

Everything appeared to turn pretty simple, don’t you think? But just imagine all brilliant advantages, all the incredible opportunities we get for freeing up the hands of artists and other people to create their own, unique, extraordinary Figure Galleries, that they will be able to exchange and share. Gosh, we could launch an industry over that! Of course, if we have YOU involved too, right?

To make a long story short: To access figures within the Figure Descriptors you add a child access within the Figure Descriptor and bind it(with its figure property) to the figure you want. You can then access the figures within the Figure Descriptor stating that the accessor is the child access.