| Re: [gef-dev] Graph Structure Proposal |
Hi, Am 09.07.2014 um 13:17 schrieb Miro Spoenemann <msp@xxxxxxxxxxxxxxxxxxxxxx>: > Hi, > see below. > >>>> in KIELER we have solved this problem using an extension point where >>>> * layout options, i.e. parameters of layout algorithms, can be declared >>>> with some meta data such as identifier, name, and data type; >>>> * layout algorithms can be declared together with a list of supported >>>> layout options. >>> >>> At least for Zest.FX, I would rather like to avoid using extension points (which might make a JavaFX standalone scenario more complex). Nevertheless, each layout algorithm should indeed provide this kind of information (that was what Matthias and I had in mind with the properties). Up to now, in GEF4 Layout this is rather implicit, which is bad. > > In KIELER the extension point is used only for generic handling of > layout algorithms and their parameters, e.g. for the user interface. The > algorithms can also be invoked independently of these meta data. > In our current understanding, we would migrate only the graph data > structure to GEF, but not the rest of our infrastructure (extension > point, service classes, etc.). Then I think we have the same understanding here. For GEF4 Graph (which is to be merged with KGraph), the parameters (extension point) would be out of scope (as the component is UI independent), while the properties should indeed be used. > > >>>> These meta data are gathered in a singleton service class. As a result, >>>> we could implement a generic "Layout" view, very similar to the >>>> "Properties" view, where a layout algorithm can be selected and the list >>>> of supported layout options is then updated automatically, so the user >>>> can access all parameters of the algorithm. >>> >>> I do not see the need for a singleton service yet. Nevertheless, it would be nice to provide these kind of parametrization options also via the UI (in Zest.FX.UI). While a distinct "layout" view could be an option, one could also think of integrating such kind of things directly into the properties view. >>> >> This is the point where the internal logic of Kieler and Zest was different. If I understood correctly, Kieler reads the graph, and based on the properties it tries to select the "optimal" layout algorithm from a selected pool. On the other hand, Zest was relying on single layouts, which were useful for including model-dependent > > No, we don't have an automatic selection of an "optimal" layout > algorithm (there has been some research on this, but it is not part of > the official release). We rather use default values as a basis, which > can be overridden in particular applications with another extension > point. For instance, you can use the extension point to specify that > your particular diagram editor A shall be handled with layout algorithm > X. Whenever you open an editor instance of A and click on the layout > button, algorithm X is selected based on this preconfiguration. > We also have other ways to configure the layout, e.g. with an API for > programmatic access to the layout algorithms and their parameters. > More details in our Wiki: > http://rtsys.informatik.uni-kiel.de/confluence/x/0IF1 OK, then I think things are pretty much comparable, only that Zest.FX/Zest.FX.UI does currently no provide a possibility to select the algorithm via the UI (thus, there is currently also no comparable extension point). > > >>>> * All graph elements are property holders. Properties have generic >>>> types, which is very useful to avoid massive type casting of property >>>> values. This concept is compatible with the layout options registered >>>> via the extension point mentioned in my previous mail. >>> >>> That's very similar to what Matthias and I had in mind with the properties. Seems to be a reasonable approach, while (as mentioned above) the need for an extension point is not yet clear to me for relating the options to an algorithm (an algorithm could also directly expose this kind of information in its interface, right?). > > The properties used in the data structure can be used independently of > the extension point. So we have two levels of information: the full set > of meta data in the extension point (for generic handling, mainly for > the UI) and a reduced set encoded as instances of IProperty (for direct > programmatic access). As said above, the properties would be relevant for GEF4 Graph, while the rest would probably be out of scope there. For Zest.FX or Zest.FX.UI something comparable could actually be needed (but up to now, this is out of the scope dicscussed here). > > >>>> * Edges may have a source port and a target port, but that is optional. >>> >>> From the experience you have gained so far, is the port concept the right abstraction, or would it rather be useful to generalize it into something like an "overlapping" of nodes? >> In my opinion, ports are different than overlapping nodes - they are similar to anchor points, but they are visible. There are very specific rules about positioning these ports; most of them do no apply to subnodes/overlapping nodes. But maybe Miro has a different use case. > > Ports are necessary whenever the anchor points of edges are constrained > to certain positions. For instance, in electric circuit schematics or > similar diagrams this is crucial to get a good layout. > A considerable amount of research in our group has been spent on the > topic of layout algorithms supporting such port constraints. Ok, then we should consider to add this to GEF4 Graph. I just asked because in GEF4 FX we do not have a corresponding concept yet. @Matthias: maybe we should add it there as well (within GEF4 MVC, this can IMHO be properly covered with the anchorage mechanism). > > >>>> Regarding the question whether to use EMF or not, we decided that we >>>> (read: the KIELER project) need EMF in any case. We have two options: >>>> * specify the data structure directly in Ecore, or >>>> * create interfaces and an EMF-independent implementation in one plugin >>>> and an Ecore-based implementation in another plugin. >>>> Even if EMF is used, it is possible to use the data structure in >>>> Eclipse-independent applications by shipping the plugins >>>> org.eclipse.emf.common and org.eclipse.emf.ecore with it. This gives an >>>> overhead of about 1.6 MB. >>> >>> I do not object to using EMF and I think that the overhead is something that we could well live with. Actually the approach you describe would facilitate the split of GEF4 Graph into interfaces and implementation, as I proposed earlier. I think from our viewpoint, the following would be desirable: >>> >>> 1) the generated interfaces should not make use of the EMF collection classes (i.e. use a plain List instead of an EList) and (if possible) should not extend EObject, so we could put them into a bundle without any EMF dependencies (I think this can be achieved by certain EMF genmodel options). >>> 2) the implementation classes could be put into a separate bundle that depends on EMF. I do not think we would have to provide a non-EMF-based implementation in addition, at least I do not see a direct use case for this yet. >>> >>> This way, the use case of writing adapters between GEF4 Graph interfaces and a custom model would remain pretty much lightweight (no EMF contracts to follow), while a transformation scenario would also be best supported (here, EMF seems to be advantageous). >> It is possible to remove all EMF classes from the interface. The only thing required is having some javadoc tags defined for the interface, after that EMF can generate everything required. I have first-hand experience with this - if we can follow the (naming) conventions of EMF, it works really well. The most problematic point I see is providing a modifiable list for multivalued attributes - this requires specific list implementations that can send change notifications (at least if we want to make the graph model dynamic). > > Would it be feasible that I send a proposal consisting of an Ecore model > file, and you generate EMF-free interfaces + EMF-bound implementation > out of it? That would probably be useful (1) to concretize our discussions about the actual changes that would have to be applied to GEF4 Graph to match your requirements and (2) to confirm whether the intended approach of separating GEF4 Graph into a set of EMF-indenpendent interfaces and related EMF-based implementation is feasible. As such, I would welcome this procedure. > > Miro Cheers Alexander > _______________________________________________ > gef-dev mailing list > gef-dev@xxxxxxxxxxx > To change your delivery options, retrieve your password, or unsubscribe from this list, visit > https://dev.eclipse.org/mailman/listinfo/gef-dev -- Dr. Alexander Nyßen Dipl.-Inform. Software-Engineer Telefon: +49 (0) 231 / 98 60-210 Telefax: +49 (0) 231 / 98 60-211 Mobil: +49 (0) 151 / 17396743 http://www.itemis.de alexander.nyssen@xxxxxxxxx itemis AG Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail