- Feb 05, 2015
-
-
Vincent Aravantinos authored
refs 2255
-
Vincent Aravantinos authored
refs 2255
-
Vincent Aravantinos authored
refs 2255
-
Vincent Aravantinos authored
refs 2255
-
Florian Hölzl authored
refs 2255
-
Florian Hölzl authored
refs 2255
-
- Feb 04, 2015
-
-
Vincent Aravantinos authored
refs 2255
-
Vincent Aravantinos authored
refs 2255
-
Vincent Aravantinos authored
refs 2255
-
Vincent Aravantinos authored
refs 2255
-
Simon Barner authored
-
Vincent Aravantinos authored
refs 2255
-
Simon Barner authored
Bugfix: Use annotation instance key in setValue(). This is already done in getValue() / getLabel()
-
- Feb 03, 2015
-
-
Simon Barner authored
-
Simon Barner authored
- Add Id, version, and ConQAT tags to XML files
-
- Feb 02, 2015
-
-
Simon Barner authored
* Mainly documentation cleanup * Remove some commented out code org.fortiss.tooling.kernel.internal.storage.eclipse.ModelContext: org.fortiss.tooling.kernel.utils.EMFResourceUtils: - Resolve B.19 issue (numbering scheme as of Aug. 14, <https://af3-developer.fortiss.org/projects/autofocus3/wiki/Check-list_for_Code_Reviews/56>) "Use static imports" refs 2255
-
Simon Barner authored
- Annotations are now instantiated in ElementCompositorService. Hence, this migration will not be required in the future. refs 2208
-
- Jan 29, 2015
-
-
Vincent Aravantinos authored
refs 2140
-
Vincent Aravantinos authored
refs 2055
-
Vincent Aravantinos authored
refs 2055
-
- Jan 28, 2015
-
-
Simon Barner authored
- Ensure that the annotation view is updated when switching between multiple projects by fixing a bug in the EAdapter registration refs 2236
-
- Jan 27, 2015
-
-
Simon Barner authored
- Fix last commit: Actually allow one connection from a IHierarchicElement (node) to a free IConnector refs 2233
-
Simon Barner authored
- Prevent multiple fan-in for IHierarchicElement -> IConnector connections (was erroneously enabled in some cases) - If this is desired, concrete compositors should override canConnectInterally() refs 2233
-
- Jan 26, 2015
-
-
Simon Barner authored
refs 2208
-
- Jan 23, 2015
-
-
Simon Barner authored
refs 1491,2203
-
Simon Barner authored
- Instead, ensure that DiagramEditorBase has the focus when a child edit part is added or removed - This works around #2207 and also the same part of #1491 as with the old workaround - Summing up: - Undo/redo of operations on the model only works if either the NavigatorViewPart or a DiagramEditorBase has the focus - This makes sense if the active view provides editable items itself (e.g., the GenericAnnotationView) *and* provides undo/redo (currently not the case for GenericAnnotationView). - For other (read-only) view (e.g., Model Markers), this behavior is confusing for the user refs 2207,1491
-
Simon Barner authored
- Fix addition of spurious undo/redo command by ensuring that annotations are instantiated from HierarchicElementCompositorBase.compose() - Derived compositors that override compose() must ensure that call their parent classes' implementation refs 2208
-
- Jan 22, 2015
-
-
Simon Barner authored
- Move annotation value service, annotation value provider base classes and annotation extension point to org.foritss.tooling.base - Remove createEditingSupport() from IAnnotationValueProviderBase and move functionality to org.fortiss.tooling.base.ui.annotation.editingsupport.EditingSupportFactory instead - Rename extension point to org.fortiss.tooling.base.annotation. Example binding: <extension point="org.fortiss.tooling.base.annotation"> <annotation binding="org.fortiss.af3.timing.annotation.valueprovider.CIValueProvider"> <modelElementClass modelElementClass="org.fortiss.af3.component.model.Component"/> </annotation> </extension - Adapt all known users of annotation framework to new structure - The change is a preparation to fix #2208, i.e. to put the instantiation of a model element and its annotations into a single undo/redo command refs 2208
-
- Jan 21, 2015
-
-
Simon Barner authored
- Avoid case distinction in GenericAnnotationView that handles construction of EditingSupport for boolean annotations - This fixes the bug that the EditingSupport was only created correctly for derived annoations (#2225) - Add TODO to delegate construction of label provider to annotation value provider, too (#2226) refs 2225,2226
-
- Jan 15, 2015
-
-
Simon Barner authored
refs 1491
-
- Jan 14, 2015
-
-
Simon Barner authored
- Fix crash in some annotation value providers during undo/redo by checking if annotation specifications are registered with a model element refs 2204
-
Vincent Aravantinos authored
refs 2133
-
- Jan 13, 2015
-
-
Simon Barner authored
- Document that getAnnotation(IModelElement modelElement, Class<T> clazz) wraps the model access into a command refs 2199,1841
-
Simon Barner authored
- Ensure that that AnnotationsUtils.getAnnotation(IModelElement modelElement, Class<T> clazz) actually wraps the extraction / creation of an annotation into a command - DAGExtractionWithoutDeployment: use this variant refs 2199,1841
-
Simon Barner authored
- If the annotations view is not visible (i.e., not opened at all, or not the active tab), create and raise the properties view - Otherwise, just create the properties view, but do not raise it (the annotation view acts as a replacement for many properties) refs 2133
-
Simon Barner authored
- Change view ID to "org.fortiss.tooling.base.ui.annotationView" and define a Java String constant for it refs 2133,1841
-
Simon Barner authored
- Eliminate superfluous override of performRequest() because of the inheritance relation: ConnectorEditPartBase -> PositionedEditPartBase -> GraphicalEditPartBase - GraphicalEditPartBase provides the desired functionality to raise the properties view, and PositionedEditPartBase does not override this behavior refs 2133
-
Simon Barner authored
- No functional change refs 2133
-
- Jan 12, 2015
-
-
Simon Barner authored
refs 2189,1841
-
Simon Barner authored
refs 2189,1841
-