Create a history step when importing SVG files #1656
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Generally the issue is that the actual import and creation of a new SVG is handled through
GraphOperationMessageHandler
which doesn't have a "syncish" way of backuping data (the only way how you could backup the data from there is by rewriting theDocumentMessage::Backup
message and fixing code around and after that you would call it, but that leads to an async backup of data meaning the "step before the import" will likely not get saved in time).So my approach was to add a
DocumentMessage::ImportSvg
... which pretty much tries to create ausvg::Tree
the same way asGraphOperationMessage::NewSvg
does... with the exception that it doesn't care about the result... only cares about the succesful unwrapingOk(_)
of theOption<Tree>
and then proceeds to send the original message (and calls self.backup(responses) before)Now ofcourse the idea of just deserializing the tree and sending that crossed my mind but after investigating serde I realized it would just be a reimplementation of their
Tree::to_string
method which seemed pointless.I'll look into what is your branching strategy and I'll submit a PR so that you can take a look at it
Maybe just to add... of course an option would be to just
self.backup(...)
on everyGraphOperationMessage
received byDocumentMessageHandler
... but that would lead to undesired behaviour with some of the other tools that work with vector graphics