Community
Participate
Working Groups
In its actual state GMF-Tooling is well tested for diagrams with dozens (small) and a few hundreds (medium) semantic elements. Working with diagrams targeting bigger semantic models (thousands of semantic elements) is known to be more problematic. This umbrella bugzilla is to cover support for those medium/big use cases. Note that there are two different "sizes" of the diagrams to be considered for purposes of this bugzilla. Even if the semantic model itself is very big, every particular diagram rarely should contain more than a few dozens top level elements to be useful. In Luna release GMFT shall consider the following improvements in this area: - performance Diagram performance should depend on the size of the *diagram* model and should have very small dependency on the size of the underlying semantic model. Small diagrams for subsets of very big models should behave very similar to small diagrams for small models. - usability of diagram subsetting Actual strategies for populating the diagrams are either "all" or "nothing". Diagram user is expected either: * start from the complete (synchronized) diagram for full semantic model and one by one remove or hide undesired contents * or start from empty (unsynchronized) diagram and one by one add desired shortcuts Neither of these strategies are good for big semantic models. There should be some ways of doing bulk operations on the "desired" subset of the model to be shown - better support for multiple diagrams for different parts of the big semantic model Also GMF-T already supports navigation between different diagrams for single semantic model (@see OpenDiagramBehavior), it is better suited for showing different aspects of the same model. - different synchronization modes from single generated code GMF-T supports synchronized and non-synchronized diagrams. However, decision about the kind of the diagram is actually made at the generation time and in order to have BOTH kinds toolsmith should generate 2 different diagram plugins. GMF Runtime allows to defer this decision to the runtime, so GMF Tooling should consider serving all sync modes from the single generated code. Additionally some intermediate sync modes may be considered: E.g, it seems that in most use cases user wants to have explicit control on the set of root nodes but still wants to have the links between existing nodes to be managed automatically.
