Add ability to reset HistoryManager

[bdionne]

The HistoryManager that supports the undo/redo functionality in the editor does not play well with the protege client. When an existing project is opened the entire change history is loaded into the manager. We need the ability to reset the history, as this is not the intended semantics in this case, rather the idea is to capture edits in the current session. Something like this workaround seems simple enough, though an interface method would be preferrable

[matthewhorridge]

When an existing project is opened the entire change history is loaded into the manager

@bdionne Please can you explain why this happens? Is it because of the way the project is loaded?

[bdionne]

When the project loads, the change history is fetched from the server in the form of list of OWLOntologyChange objects. The manager applies that list of changes.

This is somewhat mitigated in the client we're using as we load first from a snapshot, so the history applied from the server will be smaller.

[matthewhorridge]

I see, thanks. I guess these changes should be silently applied as they aren't the result of user actions. This way, the history manager, or any other object that listens for changes won't apply them. Would there be any side effects to this solution from your point of view?

[bdionne]

That works, if by silently you mean in this kind of case we'd call a different method such as applyChangesSilently ? But yea, when we retrieve these from the server they are changes already committed by someone else so we don't need to track them in history.

I do still want to be able to get at History and use the Undo functionality, which I can do as there's a getHistory on the model manager. It gives me clean way to quickly undo some of these complex operations.

[matthewhorridge]

That works, if by silently you mean in this kind of case we'd call a different method such as applyChangesSilently

Yes, something like this.

[bdionne]

As I consider it more, there's also the case of committing changes to the server, after which it would be nice to reset the history manager, or not, I can see use cases where you'd want both capabilities