Community
Participate
Working Groups
Selection behaviour is wrong after the deletion of the following schema object types: * Element references * Sequence or Choice compositors * Attributes Currently when you delete any of those elements the selection jumps to their parents. This is particularly annoying when deleting multiple objects. The correct selection behaviour after the deletion is as follows: * If there are N objects on the same level in the hierarchy and the Nth object is deleted, the N-1th object should be selected * If there are N objects on the same level in the hierarchy and any object 1 to N-1 is deleted, the N+1th object should be selected * If N=1 objects on the same level in the hierarchy and object 1 is deleted, the parent object should be selected (no more children on the same level) This behaviour is applicable when the delete is performed using the corresponding keyboard shortcut, button or context menu and when invoking a cut operation. This behaviour is implemented by the Simple Cheat Sheet Editor - if you need a reference. Now currently, multiple selection is allowed in the tree viewer. This complicates things. I recommend disabling multiple selection unless Wassim objects because there are a number of other bugs that exist because of it.
Curtis finds the multiple selection useful for copy and paste operations. Plus, the deletion of multiple objects at the same time is convenient. Therefore, if we can overlay the behaviour outlined in Comment #0 on a multi-selection enabled tree viewer that would be ideal. A set of heuristics would have to be defined as all edge cases where more than one object is selected probably will not be solved.
Created attachment 74613 [details] patch The new selection was being set in the model change handler for the ElementSection. I removed the call to set the selection here and left it up to the handleDelete method. This method is used for cuts and deletes, so both of those cases are fine. Doing this actually fixed a flicker that occurred on a move operation because the selection was changed on both the model remove and the model insert. I cannot think of any other edge cases where the handleDelete event is not used and we would actually want the model change handler to set the new selection. The selection algorithm for deletes now works as suggested in comment 0. It is, of course, slightly modified to allow for multiple deletes at once. It will base the new selection on the object selected for deletion that is highest up in the hierarchy (elements > compositors = attributes > references). If multiple items are selected for deletion that are at the same level, the algorithm will use the first it comes across. If, however, a subsequent delete removes the new selection candidate, the selection will be regenerated based on that object. That was a little wordy. I hope it made sense. If it didn't, it will when you see it in action. ;)
Created attachment 74621 [details] patch Modified the logic to determine what's higher in the hierarchy. It is now based entirely on how deeply nested a SchemaObject is from an element. For instance, attributes are now considered higher in the hierarchy than nested compositors and references on the root compositor are considered higher than compositors nested at lower levels. A compositor and a reference are considered equal if they have a parent compositor at the same level.
Comment on attachment 74621 [details] patch Tested very well. Excellent work Adam.
Patch released to HEAD. Target: 3.4 M1
