From: Chris C. <ca...@al...> - 2002-08-12 18:25:28
|
Richard Bown wrote: > Keeping a vector pair of old Events/MatrixItems when you execute the > push and then rematching and rewiring after the command is executed. Let me just go through this. Your problem (as in your example of wanting to move some things and then resize them without having to reselect) is that when you execute an operation like move, the events are deleted and recreated and thus removed from the current selection. (Actually, your _original_ problem was that they were being deleted but not removed from the selection, so you'd get a crash when you next tried to use the selection. This meant you had to explicitly clear the selection after the move. Is that right? But one of my changes this afternoon should have ensured that the events really do get removed from the selection automatically when they're deleted, so it should no longer be necessary to clear the selection explicitly. But it's still a problem that the events are no longer selected, and that you can't easily identify them any more to reselect them.) But as you said, there aren't very many places where commands of this type (i.e. commands where it's useful to keep the selection active) are executed. For the moment it's probably good enough to deal with them on a case-by-case basis. So why shouldn't a method like MatrixMover::handleMouseRelease just be able to query each of the MatrixMoveCommands it creates (after the addCommandToHistory has happened) for the new event it created, and then to add all those events to the selection explicitly in handleMouseRelease? It can't be difficult: MatrixMoveCommand can easily store its newEvent and return it when asked for. The interesting thing is how easily this can be done generically -- we could do with it in a few places in the notation view as well. See NotationView::slotEditPaste in notationviewslots.cpp for instance, where after the paste we select all the events in the pasted region (which will contain all the pasted events, but may also contain any number of events that we didn't just paste and don't really want to select). Perhaps some sort of base Command class that can be queried for a set of the new Events it created, plus a special subclass of KMacroCommand that returns the union of the sets of "new" Events generated by all of its contained commands (if the commands are of the right type). Chris |