Hi Emil, hi Wim,
I have contributed almost every change I have made locally. There is just one left. But that one is also quite huge. It's about undo/redo handling. Even for deleting events and sections. I have rewritten a lot of code regarding undo/redo. As I just noticed that Wim also did something on that a year ago, I wanted to talk to you before I contribute. Maybe I can adjust my changes so they don't hurt others too much.
Here are my questions:
In the ClusteredCommand Wim added the methods public List getCommands() and public List getEvents(). getCommands() unpacks the clustered commands to have a flat collection. And the returned list ist unmodifiable. Now this fact hurts my implementation, where I simply return the local referenced collection _commands.
The reason why I need the collection itself modifiable is that it needs to be possible to change the order of the events. This is because a) if you delete more events at once, the order of the events on restoring depends on the order how they where selected. Therefore the stair effect breaks on undo b) if you e.g. want to delete a section automatically if the last event was deleted in the section, you need to change the order of the commands dependent if you undo or redo, as on undo you need to first undo the section delete and then the event delete, on redo you need to switch. It is also necessary in this case to keep the clustering in the cluster if there is any. So the two implementations of getCommands() collide.