| Re: [gef-dev] Graph Structure Proposal |
Hi Alexander, sure, sounds like a good idea. I will be on vacation next week and will start on this the week after. Cheers, Christoph Daniel On 02/10/14 18:23, Alexander Nyßen wrote: > Hallo Christoph Daniel, > > I would propose that you incorporate your changes on GitHub then (maybe > Miro can pull them into the master), so we can continue our discussion > based on a consolidated state there. > > Cheers > Alexander > > Am 26.09.2014 um 23:08 schrieb Christoph Daniel Schulze > <cds@xxxxxxxxxxxxxxxxxxxxxx <mailto:cds@xxxxxxxxxxxxxxxxxxxxxx>>: > >> Hi Alexander, >> >> On 25/09/14 10:34, Alexander Nyßen wrote: >>> That sounds reasonable. Do you need to listen to changes of individual >>> values like x, y, width, height, or would it be sufficient to listen for >>> changes of 'position', 'size', etc.? The second one will probably also >>> be provided when using GEF4 Geometry, while the first case is not >>> supported there (GEF4 Geometry does not provide any change listener >>> mechanism yet; and I am not sure if it should). >> >> Since the values of the Points and Dimensions could well change without >> the actual objects being switched, just listening for the latter >> wouldn't work for us. >> >>> In either case, if we decide against GEF4 Geometry, I think I would also >>> opt to directly use primitives (doubles) instead of introducing new >>> abstractions like KPoint. >> >> Agreed, although with bend points we will probably still need this kind >> of an abstraction. >> >>> I understand. Actually I forgot to include the KLabeledGraphElement; I >>> did not want to do away with it. >>> >>> I would then propose to eliminate the KEdgeLayout interface (as already >>> discussed) and to rename the KShapeLayout-interface into KShape. That >>> way, the used terminology should be consistent. >> >> Sounds great. >> >>> Up to now that has been provided via the property/attribute mechanism. >>> With Zest.FX we have started to use CSS classes/ids/styles to specify >>> the rendering. These are provided via the property/attribute mechanism >>> (potentially augmented by an external CSS stylesheet). >> >> So it wouldn't make sense for you to add rendering information to a >> dedicated field in the graph structure? >> >> Cheers, >> Christoph Daniel >> >> -- >> Christoph Daniel Schulze >> >> Christian-Albrechts University of Kiel >> Department of Computer Science >> Real-Time and Embedded Systems Group >> >> Room 1112 >> Phone +49 (0)431 880-7297 >> >> Olshausenstr. 40 >> 24098 Kiel >> Germany >> >> >> _______________________________________________ >> gef-dev mailing list >> gef-dev@xxxxxxxxxxx <mailto: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-202 > Telefax: +49 (0) 231 / 98 60-211 > Mobil: +49 (0) 151 / 17396743 > > http://www.itemis.de > alexander.nyssen@xxxxxxxxx <mailto: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 > > > > > _______________________________________________ > 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 > -- Christoph Daniel Schulze Christian-Albrechts University of Kiel Department of Computer Science Real-Time and Embedded Systems Group Room 1112 Phone +49 (0)431 880-7297 Olshausenstr. 40 24098 Kiel Germany
Attachment:
signature.asc
Description: OpenPGP digital signature