I would opt for org.eclipse.gef4.cloudio.
Cheers Alexander
Von meinem iPhone gesendet
+1, moving Cloudio into a GEF4 component of its own sounds good to me.
Do we keep it in the org.eclipse.gef4.zest.cloudio namespace? Or should we take this as the starting point to gradually move the Zest bundles into the org.eclipse.gef4 namespace (o.e.gef4.cloudio, o.e.gef4.layouts, etc.) and move Zest from a visualization component to a collection of visualization components?
Cheers, Fabian Hi all,
as a first starting point, let me propose the following (I had already tried to start a discussion on this in bug #372365 some while ago):
As the GEF4 Zest Cloudio plug-ins do not depend on any other GEF or GEF4 plugins, what about first modularizing them into an own GEF4 Cloudio component so they could also be consumed individually as well? If you guys agree, I would opt to perform the refactoring, so that we obtain something in the shape of Geometry and SwtFX (i.e. with doc plug-in and sdk feature).
Cheers, Alexander 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
_______________________________________________
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
|
