Community
Participate
Working Groups
If the user accidentally changes something and then undoes it, the editor should be marked clean. If the user saves, then invokes UNDO, REDO, the editor should be clean. In both cases GMF leaves the editor marked dirty, which prevents closing the editor without being prompted to save. This behavior is inconsistent with platform text framework and normal GEF editors such as the Logic example. Reproduced in the GMF version of the logic example.
Marking as minor for 1.0.1 as there are workarounds.
Could you please share the workaround? As far as I know, the workaround is quite involved since GMF does not use the GEF commandstack.
The end user has a workaround by cancelling the save dialog.
The possible reason is: GMF currently listening for the resource changes using FileDiagramModificationListener (attached to the diagram file in FileDiagramDocumentProvider.createFileInfo()), but not for the CommandStack like EMF-generated editor.
Moving to the next release, GMF 2.1.
Hi Alex, here we should see we can fix in 2.1.
The command stack has this functionality built in. If it's notified when a save occurs, it will place a marker at the current location in the stack, and its isSaveNeeded() method can be used to query whether the diagram is dirty. To notify the command stack of saving, ((BasicCommandStack)getEditingDomain().getCommandStack()).saveIsDone(); can be placed in FileDiagramModificationListener's notifyChanged method. However, GMF's actions don't appear to be routed through the (emf) command stack. Theoretically, there's somewhere along the call path of GlobalUndo/RedoAction.run() where we could put ((IEditingDomainProvider)getWorkbenchPart().getAdapter(IEditingDomainProvider.class)).getEditingDomain().getCommandStack().undo(); and with all that tracking in place, then the editor's dirty state need only be sync'd to isSaveNeeded(). In practice, haven't been able to do that yet, deferring continued work on this till later.
Hi, I get the same bug when doing these actions : - open a diagram - move a node - undo The diagram is still dirty. Is the workaround provided can fix that too ??
The workaround was just to cancel the save dialog when you close the editor so that the resource is reverted to its original state. It will work in your case, too.
Well, I was asking about comment #7 :)
Adding dependency on bug 240775, which will allow GMF to provide its own policy for when to add the ResourceUndoContexts for operations affecting its resources. Our policy will exclude notifications on transient features, in order to match our the logic in GMFResource that overrides ResourceImpl.ModificationTrackingAdapter to exclude notifications on transient features.
In reply to comment #10, the solution I am working on now will fix the scenario that is described in comment #8. In GMF we use the isModified state of the resource to determine whether or not a given GMF editor is dirty. In order to remove the dirty marker from GMF editors when changes to the resource are undone back to the last save point, my approach will be to make use of the ResourceUndoContexts added to undoable operations by the WorkspaceCommandStackImpl.DomainListener. This approach assumes that if an operation has a ResourceUndoContext for a given resource, then the operation has in some way changed the state of that resource. Once all operations with the context for a given resource have been undone back to the last known save point, if the resource is in a GMF editing domain I will set the isModified state back to false.
Added a new GMFResourceModificationManager to manage the isModified state of resources in a given GMF editing domain. Editing domains created through the GMFEditingDomainFactory are configured with a GMFResourceModificationManager. 10 new JUnit tests in org.eclipse.gmf.tests.runtime.emf.core
Fix available in HEAD: 2.2.0M3.
[GMF Restructure] Bug 319140 : product GMF and component Runtime was the original product and component for this bug
