Re: [gef-dev] Connection decorator for Zest - Some review needed

[Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>]

Hi,

thanks for the feedback. I was thinking among the same lines, thats why I pushed first and then asked... :D

I was also thinking about such a migration lately (yeah, we are sometimes using Zest and it would be nice to have some release :) ), and was already looking at the SwtFx documentation for this reason, but I have nothing tangible yet, and based on my previous record, I don't want to promise anything. :)

However, thanks for your interest in this merging.

Cheers,
Zoltán
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

On 2013.10.18., at 9:55, Alexander Nyßen <alexander.nyssen@xxxxxxxxx> wrote:

> Hi Zoltán,
> 
> while I haven't looked into the details yet, let me at least say something to 1): When we initiated GEF4, the basic idea was to have a provisional API, which we could shape independent of those API constraints we are currently facing at GEF proper (including Zest 1.x). As such, we should IMHO not restrict ourselves to keep the Zest2 API stable (even if we break adopters by this) as long as this prevents to make it more concise (of course we will have to point out those issues in the Zest 2 migration guide). 
> 
> Something else (but related): We had already started a discussion (within bug #372365) on how to perform a migration of the Zest2 code base to solely rely on other GEF4 components, and no longer on GEF proper ones. As Matthias has now spent quite some effort in building up the GEF4 SwtFx component (which is not yet finalized, but has made some progress; the Graphics related parts are already quite far), it may be worth to pick this up again. I have already talked to Matthias these days and we decided to take a deeper look at Zest2 to identify, which parts could already be migrated and how this could happen (we will report the results to bug #372365 so you "Zest guys" can comment on it).
> 
> Cheers,
> Alexander
> 
> Am 17.10.2013 um 18:37 schrieb Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>:
> 
>> Hi,
>> 
>> recently we had a need for a feature request for Zest to define alternative arrowheads for edges (I have also opened a ticket for it https://bugs.eclipse.org/bugs/show_bug.cgi?id=419736). Currently, this was not supported in Zest.
>> 
>> However, I played a bit with the code base, and I have not a seemingly working implementation (and have already pushed this to master).
>> 
>> The basic idea is similar to ConnectionDecorator support:
>> * A Graph may define a decorator for both directed and undirected edges
>> * A GraphConnection may define a custom decorator, or rely on either the graph's default directed or undirected decorator (as defined by the style bit)
>> * This can also be set up in the JFace label provider
>> 
>> Example snippets are also created:
>> * Graph API: http://git.eclipse.org/c/gef/org.eclipse.gef4.git/diff/org.eclipse.gef4.zest.examples/src/org/eclipse/gef4/zest/examples/swt/ConnectionDecorationGraphSnippet.java?id=51d070e68a226cae98b0a51c867979ac5cbca014
>> * JFace: http://git.eclipse.org/c/gef/org.eclipse.gef4.git/diff/org.eclipse.gef4.zest.examples/src/org/eclipse/gef4/zest/examples/jface/ConnectionDecorationJFaceSnippet.java?id=51d070e68a226cae98b0a51c867979ac5cbca014
>> 
>> However, I would like to have some feedback:
>> 1. The current implementation modified the IConnectionStyleProvider interface from the JFace API that would break its users. As we have already broken the API Zest 1.0 users, this might not be that serious, but if its a problem, I am open to change it in a compatible way.
>> 
>> 2. The proposed implementation might replace entirely the DIRECTED style bit (the same functionality can be implemented with the new API by providing different default decorations). Is it worth to keep that as well?
>> 3. This implementation could be extended to also support other special arrow styles, such as dotted, etc.
>> 
>> Points 2. and 3. might simplify the API that would be nice when considering a future port to the new Graphics4 API as well, but I am not sure whether its the best direction.
>> 
>> I welcome any feedback, and of course I am open to change any part of the implementation, it is for now only a short experiment whether it works or not.
>> 
>> Cheers,
>> Zoltán
>> -- Zoltán Ujhelyi
>> https://www.inf.mit.bme.hu/en/members/ujhelyiz
>> 
>> Fault Tolerant Systems Research Group
>> Budapest University of Technology and Economics
>> 
>> _______________________________________________
>> gef-dev mailing list
>> gef-dev@xxxxxxxxxxx
>> 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
> 
> 
> _______________________________________________
> gef-dev mailing list
> gef-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/gef-dev