I am glad you have addressed this.
My apologies - I had always put up with this slightly annoying ergonomic behaviour in CHS, supposing it to be a CHS "foible" that you would have known all about and would have fixed if you had thought it was a problem, and so I never thought to mention it, but just worked around it.
I guess the lesson there is, don't make assumptions... EDIT:
Just some quick feedback. I confirm that, now, after deleting a clip (a row in the Grid
pane), the selector rests one clip forwards
- i.e., on the next
clip down - which is probably what one would intuitively expect to happen.
If the clip being deleted is the last (bottom-most) clip in the Grid
, then, after deletion, the selector rests on the immediately preceding
clip - which again is probably what one would intuitively expect to happen.
(In both cases, the context
is when the Grid
is currently sorted in Modified
date order - which is what I usually have it in. I have not yet tested it in the contexts of differently-ordered states.)NB:
As an observation, I would point out that this behaviour is not
what seems to have been requested in the OP, where the expectation there seems to be that, after clip 40
in a list of 100 was deleted, the selector would be positioned on clip 39
, one clip back
(i.e., on the preceding clip, not the following clip), after the deletion.
I would thus consider this OP request to be incorrect - ergonomically counter-intuitive - and that you have fixed it to work in a more ideal ergonomically intuitive manner that would make sense in the context where you were (say) deleting clips successively, one by one, in the Grid
. That is, you would want the selector to rest on each one to be deleted in turn - downwards
- rather than skipping back to the penultimate one selected but not deleted. Again, the context of the sort order might be relevant here. Quite tricky really.