https://bugs.kde.org/show_bug.cgi?id=443324
--- Comment #9 from biblio...@gmail.com --- (In reply to emohr from comment #8) > Question to your point 2): we have 3 clips on a track: A, B, C. A and C are > grouped. You click with spacer on clip C. Should A and B also move in the > spacer operation? $One-million question! Strangely, my reply is: A should, and B shouldn't. Maybe, it is to be discussed with experts (I am not), but in my general and formal view, as you Spacer click on an element, and if the element is a part of a group, what should move is the respective group as a whole (treated as a single element), and all the elements to the right of the group. In our case, A & C are to move as a group, and B shouldn't because B is not right to the group! In my understanding, the group, if it is a group, should be treated as one element consistently. Following the above: (1) I suppose the Spacer algorithm could reliably work like it did in case of clicking the leftmost element of a group (no crashes in that case were detected), the only correction expected is that the first moving element should be the leftmost element of the clicked group. And, by the way, the group should not treated as temporary like other moving elements to the right of it. )) (2) Maybe, the whole practice of grouping non-adjacent clips in one track should be considered weird. )) The practice of grouping not adjacent -- You are receiving this mail because: You are watching all bug changes.
