Bugzilla – Full Text Bug Listing
| Summary: | [GMF] Basic GMF Fetures should also be available in GEF | ||
|---|---|---|---|
| Product: | [Tools] GEF | Reporter: | Vijay Raj <vijay.rajonline> |
| Component: | GEF-Legacy GEF (MVC) | Assignee: | gef-inbox <gef-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | developer, ian.leslie, irbull, kompiro, mariot.chauvin, nyssen |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Vijay Raj
In general I'd agree with that. However, I'm not sure whether this would really make sense (see my analysis below). Besides, I'm afraid that this would break many existing applications. So it would only be possible to copy (and not move) some features to GEF (and mark them deprecated in GMF) -- but duplicated code is always a bad idea. Since your proposal is a little bit too general, I'd like to look at the possible candidates a little bit closer. (In the following, I mean Draw2D and GEF when I write GEF). I would suggest to categorize these "features" as follows: 1) simple bugfixes 2) often used helpers for GEF classes implemented in GMF 3) general GMF utility and helper classes (with no EMF dependencies) 4) "real" GEF enhancements in GMF 5) EMF or notation model dependent features to 1) I strongly agree to at least "copy" category 1) classes to GEF. But I'm not sure whether there are too many open bugs left in GEF. E.g., the RubberbandSelectionTool does fix a bug once present in MarqueeSelectionTool, but this bug has been fixed meanwhile. Does anybody have a list of classes falling into that category? to 2) I'd assume with Zoom, Print, and Export features you mean classes build "around" existing GEF features, do you? I mean, GEF support zoom and print and you need only a few lines to add these things to your own GEF editors. Export may be a little bit more work, and a class such as CopyToImageUtil seems to fall into that category. However, I haven't examine the dependencies of that utility class. Maybe a list of possible candidates (and their dependencies) would be helpful. to 3) There are some GMF utility and helper classes with no EMF dependencies, often used in GMF's "pure" GEF parts. E.g., org.eclipse..gmf.runtime.common.core.util seems to be a candidate. However, I'm not sure which of these classes make sense in GEF, and which are too specific (such as Trace, but there are many classes using Trace). to 4) Probably, org.eclipse.gmf.runtime.draw2d.ui.graphics seems to be a candidate. This plugin has dependencies to org.eclipse.gmf.runtime.common.core and org.eclipse.gmf.runtime.common.ui, but I haven't looked into that further. However, I could think of many more GEF enhancements in other projects as well. E.g., GEF3D also provides some classes which are not 3D related (see org.eclipse.gef3d.ext). But I'm not sure if it would be a good idea to move/copy all that stuff to GEF. I'm afraid that would only bloat GEF, maybe it would be a better idea to set up a (wiki) page with links to other projects and what they provide. Eventually, you can always import non-GEF plugins as well or (in the worst case) copy code from other projects. to 5) I'm afraid most of the "user friendly features" you mention are related to GMF's notation model. All these graphical properties you mention (line style, color etc.) are notation model related, so you cannot move them to GEF (unless you move the whole GMF notation model to GEF). So, if you need these things, why not simply use the GMF runtime? All in all, I'm not sure whether it really makes sense to spend much effort in this area. If you could provide a list of classes (falling into category 1)), that would surely be very helpful. Regarding category 2), dependencies have to be analyzed carefully. Regarding features falling into 3) to 5), I'm not sure if it really would make sense to move these things to GEF. Why not simply import the required GMF (or other) plugins? Jens Frankly speaking i was not expecting such a reply for the change... I knew that the change is a major one and all efforts are being put into GMF... I have developed 5 or 6 GEF views*(Not editors) in which i required zoom,print,export and autolayout etc... Since all the views were in one application i could build a framework and reused all these functionalities... I imagined everybody who is using GEF going thru the same process and thats why i thought GEF should also by default contain some of them.. I think at least GMF.draw2d enhancements and bug fixes should be moved to draw2d Thumbnail - Thumbnailex Polyline - PolyLineX RectilinearRouter and others etc which come from GMF.runtime.draw2d* plugins.... appart from this autolayout with animation is also one of the frequently rewriten code... Export to image is also a frequently rewriten code, especially large images export(Export to HTML in GMF) I think we should have a CopyToImageUtil and CopyToHtmlImageUtil for GEF also with plain figure instance as inputs... I was not able to understand the dependency of GMF diagram and EditPart class there because of which the code can not be reused directly... Apart from all this i will try to give a concrete list of classes which could be moved to GEF or drw2d from GMF.. -- Thanks and Regards Vijay *** Bug 300141 has been marked as a duplicate of this bug. *** As Draw2d and GEF (MVC) 3.x are in maintenance mode now, resolving this as WONTFIX. The changes would impose an API-break on GMF, and I suppose that is not desired either. Adapters, who want to use the GMF features can specify dependencies to the GMF runtime to make them available. |