Date: Fri, 29 Mar 2024 06:02:00 +0000 (UTC) Message-ID: <651640021.6479.1711692120217@2f9704fbf185> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6478_1377937946.1711692120216" ------=_Part_6478_1377937946.1711692120216 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Legacy Project
KARMA is not maintained anymore and hence not part of any KIELER r= elease.
Responsible:
This plugin aims to provide tools that make it easier to change the appe= arance of the diagram. A diagram using this has to do mainly three things.<= /p>
The following changes that have to be done in the EditParts of all eleme= nts that should use the mechanism.
These changes are ideally done in the GMF templates so that they can be = automatically generated.
In the RenderingProvider, implementing the IRenderingProvider given by t= his project, the figures that should be displayed are defined. The Renderin= gProvider is given a string written in the extensionpoint, which is used to= identify what Figure should be constructed. It could be a path to an svg o= r just a name to be handled be the developer or anything the user can think= of. The RenderingProvider is also given the old figure thats currently dis= played. This is for the purpose of just changing a few attributes of the fi= gure instead of building an entirely new one. For Example it is not possibl= e to change the Figure of a connection. It is possible however to change th= e style of a connection. In this case one would change the style of the giv= en oldfigure and then return that one. Finally it gets the model element. A= part from the figures the RenderingProvider can also describe LayoutManagers and BorderItemLocators in a similar way.
Most work is done by the extension point. Here the RenderingProvider is = registered as well as some EPackages that contain features to be used by th= e conditions, a number of EditParts the mechanism should be applicated to and of course the conditions = them self. An extension also has a priority which is used the order of conf= igurations in case there are more than one for the same EditPart. The default priority is 1.
This condition checks for the value of a feature thats part of an ePacka= ge. The first field is the name of the feature itself. The second the name = of the classifier that owns the feature. Third the value the feature should= have, could be a boolean or an enumeration(feel free to demand support for= more if needed). And last the strings that will be given to the RenderingP= rovider to identify the Figure, LayoutManager and BorderItemLocator to be displayed under this conditi= on.
Similar to feature value condition but instead of a value it has a size.= Other than simple numbers the size field also supports things such as >= , <, !=3D, etc.
The compound condition works like a logical "and" for all its child cond= itions.
The custom condition can be anything that implements ICustomCondition. T= he key and value fields are given to the initialize method. An example of t= his is the AnnotationCondition.
This condition tries to get an Annotation from an Annotatable with the n= ame of the key. It then checks for the type of the Annotation and tries to = parse the value to an appropriate type and then checks whether it equals th= e value of the Annotation. This condition works only for direct child annot= ations. For more hierachy layers use the RecursiveAnnotationCondition which= otherwise works in a similar way.
This condition checks if an annotation with the name of the key exists a= s a child of the given EObject.
For example states or entities.
By setting the figureparam field you can = change the appearance of a node. After evaluating the conditions the corres= ponding string will be given to the rendering provider. Using this string y= ou decide which figure should be drawn in this case. Usually this means hav= ing a lot of if else cases und pointing to methods returning an implementat= ions of a draw2d IFigure interface.
Similar to the appearance you get to deci= de on the LayoutManager to be used by the figure. This LayoutManager is an = implementation of the draw2d LayoutManager interface. The layoutmanager is = usually used to determine the size of a node with its children and the posi= tions of child figures.
Its also possible to set a size for the n= ode. The fixed size field accepts values in the form of x,y. Alternatively = if no size given here it can also be determined by giving the figure some b= ounds while doing the appearance or by using the layout manager.
Since the node is likely not a borderitem= there is no reason for it to have such a locator, ignore the field in this= case.
Such as ports and labels.
can be used the same way a for nodes.
You can give the borderitem a custom bord= eritemlocator in a similar way you give it a new LayoutManager. Return an O= bject that implements the gmf IBorderItemLocator interface. A borderitemloc= ator is used to determine the location of the borderitem relative to its pa= rent object.
Just that, a connection between two nodelike objects.
You can't give a connection a completely = new appearance due to technical restrictions. Thats not really a big proble= m though since connections are usually some kind of line anyway. You can ho= wever al least alter the appearance a bit by influencing the old figure giv= en to the rendering provider. For example its possible to change the source= and target decorations, having a dashed line, changing the line thickness = and so on.
These fields should be ignored in this ca= se since they are not really fitting to the concept of a connection.