Community
Participate
Working Groups
Currently used FileDiagramDocumentProvider works incorrectly with real diagrams (notation and semantic model loaded from tge different EMF resources). In particular: - diagram editor will be marked as dirty only if diagram EMF Resource was modified - all *Rules returned by this provider wraps only diagram resources -> the rest of the loaded resources can not be correctly saved, etc. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=112825) - FileDiagramDocumentProvider listens only for diagram file changes in eclipse Resources subsystem -> the rest of the loaded EMF resources (semantic model files) could be changed on disk without corresponding processing (refresh) in diagram editor - eclipse Resource renaming processed only for diagram file - save action saves only diagram resource I suggest to create separate class ResourceSetDiagramDocumentProvider based on EMF ResourceSet internally and implementing all these requirements.
Created attachment 53827 [details] Implementation of the corresponding DocumentProvider
Attached patch conteins required DocumentProvider implementstion. Currently tooling re-generate this implementation for each diagram. Once this patch will be commited, generated code will be able to use it.
Created attachment 59606 [details] More correct version created This version works without any *EditorInputProxies + with EMF URIEditorInput
Comment on attachment 53827 [details] Implementation of the corresponding DocumentProvider New version created
Without this class generator always produce a lot of identical code.
Created attachment 59772 [details] Removing ResourceSetModificationListener in ResourceSetInfo.dispose()
*** Bug 174501 has been marked as a duplicate of this bug. ***
Hi Alex; The Attached Patch does not filter touch events So, i have modified it to do so. Take a look at the modified pacth and let me know what do you think. If you agree the change is acceptable i can commit the change
Created attachment 64111 [details] Tacking care of touch events
Now GMF is generating RCP-compatible code. Different DocumentProvider should be used in this mode. Nevertheless, huge part of ResourceSetDiagramDocumentProvider could be reused in RCP mode too. So, to my understanding the best solution would be to split ResourceSetDiagramDocumentProvider on at least 2 classes – RCPDiagramDocumentProvider and IDEDiagramDocumentProvider. First one will support URIEditorInput, second will subclass RCPDiagramDocumentProvider and support FileEditorInput in addition. What do you think of this? I can provide you with modified patch if you agree it make sense and point me to the appropriate plugin for RCPDiagramDocumentProvider (org.eclipse.gmf.runtime.diagram.ui.resources.editor ?).
Any news about comment #10?
Since this is marked major we need to do something with this Bugzilla. Comments?
I second Alex's proposal in comment 10 to split up the implementation so that we can have an RCP-compliant version of the document provider in addition to the one with IDE dependencies.
(In reply to comment #13) > I second Alex's proposal in comment 10 to split up the implementation so that > we can have an RCP-compliant version of the document provider in addition to > the one with IDE dependencies. I agree this sounds like a good idea. But since I知 moving to another team on June 15, and have other work to do in the remaining 5 days, i guess it might make more sense to move the defect to someone else to think about the best way to do it.
Alex, I am taking over this bugzilla from Mohammed. In response to comment#10, yes, I think that org.eclipse.gmf.runtime.diagram.ui.resources.editor plugin is the correct place for the RCP version. So you will split up the original class into the RCP and IDE versions?
Not sure if this is 2.0, 2.0.x or 2.1.
I'd say 2.0 but it's too late. Perhaps, 2.0.1 then?
(In reply to comment #17) > I'd say 2.0 but it's too late. Perhaps, 2.0.1 then? 2.0.1 then.
Moving to GMF 3.0
[GMF Restructure] Bug 319140 : product GMF and component Runtime Diagram was the original product and component for this bug
