Advice on migrating an app from GEF 3 to GEF 5 (MVC) [message #1776693] |
Mon, 20 November 2017 14:24  |
Eclipse User |
|
|
|
We have a fairly popular modelling tool called Archi (https://www.archimatetool.com) that uses the old GEF 3/Draw2D framework to render its diagrams. It uses an underlying EMF model, GEF's CommandStack and a bunch of bespoke code to connect EMF to GEF's Editparts, Figures, Policies and Eclipse's Editor Parts. It doesn't use GMF at all.
I'm now thinking about what it would take to migrate this part of the app to GEF 5 and the MVC part. So far I haven't found any substantial examples.
Any advice? Is it possible?
|
|
|
Re: Advice on migrating an app from GEF 3 to GEF 5 (MVC) [message #1776914 is a reply to message #1776693] |
Wed, 22 November 2017 18:32   |
Eclipse User |
|
|
|
There is no direct migration path. GEF MVC is based on JavaFX as rendering technology, which has some implications. Furthermore, we have applied some conceptional changes:
- We no longer have a specific controller abstraction for connections, but a generic anchorage-anchor relationship that can be established between visual parts (which correspond to edit parts in GEF-Legacy MVC.
- We have introduced explicit controllers for feedback and handles and thereby have made them first-level concepts.
- We have modularized the interaction logic into gestures, handlers, and policies, which adds much more flexibility.
- We no longer use an own command stack but rely on the IOperationHistory.
As a starting point, you can consider the documentation that is provided at https://github.com/eclipse/GEF and the related wiki. Next, there is a (free) step-by-step MVC-tutorial provided by itemis (https://info.itemis.com/en/gef/tutorials), which might be good to get into touch with it. Last, you might want to study the GEF MVC logo example in more detail. It basically employs all features of the MVC component.
|
|
|
|
Re: Advice on migrating an app from GEF 3 to GEF 5 (MVC) [message #1776918 is a reply to message #1776917] |
Wed, 22 November 2017 18:57   |
Eclipse User |
|
|
|
With respect to rendering/scaling I would say absolutely yes. Take a look at our MVC Logo example. It offers continuous zooming. SVG rendering does not come out of the box. You would have to translate your shapes to SVG yourself, which is hard if you want to do it generically, but relativere easy if you know your shapes.
|
|
|
Re: Advice on migrating an app from GEF 3 to GEF 5 (MVC) [message #1776933 is a reply to message #1776918] |
Wed, 22 November 2017 22:10   |
Eclipse User |
|
|
|
OK, thanks for the advice.
I'll certainly take a look at the examples, and the available resources.
Exporting a diagram to a SVG format file is a must-have for our users. Presently, we use a hacked class taken from GMF to convert from SWT Graphics (GraphicsToGraphics2DAdaptor) and some Batik SVG classes. So, I wonder if anybody has done this? Or are developers saving to PNG and similar formats?
P.
|
|
|
|
Re: Advice on migrating an app from GEF 3 to GEF 5 (MVC) [message #1776965 is a reply to message #1776951] |
Thu, 23 November 2017 10:03   |
Eclipse User |
|
|
|
OK, thanks again for advice.
One final thing I need to check is the integration with Eclipse's Editor Parts and the use of the Palette. It seems that a lot of GEF3 apps use the GraphicalEditorWithFlyoutPalette class, and register actions with GraphicalEditor (sub-class of EditorPart) to integrate with menus and so on. Is this something supported in GEF5?
P.
|
|
|
|
|
|
|
|
|
|
|
Re: Advice on migrating an app from GEF 3 to GEF 5 (MVC) [message #1819389 is a reply to message #1819299] |
Tue, 14 January 2020 11:41   |
Eclipse User |
|
|
|
Frank Benoit wrote on Sun, 12 January 2020 17:21Hi Phil Beauvoir
did you succeed in the migration? Is there some advice you can share?
Frank
No, I didn't even try.
I couldn't find a non-trivial example of an RCP app that uses GEF5 to see how it performs, Also, I don't want to invest in JavaFX as I believe performance will be slow.
Finally, I don't have a spare two years of time to even attempt it.
|
|
|
Re: Advice on migrating an app from GEF 3 to GEF 5 (MVC) [message #1820834 is a reply to message #1819389] |
Thu, 30 January 2020 00:08  |
Eclipse User |
|
|
|
Hi,
there is a tool developed at itemis that I would consider non-trivial, using current GEF, and you can check it out for free (trial license): YAKINDU ModelViewer
Make sure to try the signal tracing feature, it looks quite good IMHO, making combined use of JavaFX effects and animations to show data actually "flowing through the wires" :-)
Besides, the GEF mind map tutorial is still being continued. A part about Eclipse integration should now be available, and a part about automatic layout is in the works. I hope the tutorial will be extended further over time, until most GEF features are presented properly. It should already suffice as an introduction to the framework, and as stimulation for your inspiration in terms of forthcoming migration efforts, in case you dare the consideration.
In my personal experience, JavaFX performance can be really good, even for complex interactions and scenes, but you have to avoid some pitfalls:
- avoid expensive computations during interaction (i.e. perform computations beforehand)
- try to minimise the number of nodes in a scene (e.g. shaping contents accordingly, for example, using "folding" or other structural means)
Although you will not need any advanced techniques for the usual viewers/editors, there are also tricks for rendering very large scenes, unfortunately not built-in. You can use mechanisms such as pagination, level-of-detail, and off-screen rendering. All of which can greatly restrict the number of nodes in a scene by omitting invisible nodes, or rendering large parts of the whole as a single unit, or rendering parts of a scene to an image for expedited display, respectively. Typical examples are:
- off-loading / on-loading on-demand
- replacement of many connections that are very close to each other with a single bigger line
- replacement of parts of a scene with a snapshot (e.g. while zooming)
I would be surprised if you actually needed to implement any of these to achieve adequate performance, and it would certainly not be a task implemented straight-forwardly, but nonetheless, it would be doable.
There is lots of published material w.r.t. performance-tuning of scene rendering, mostly originating from the game development community. In most cases, however, it is much easier to shape the contents so that very large scenes are simply avoided.
Best regards,
Matthias
|
|
|
Powered by
FUDForum. Page generated in 0.29118 seconds