Change Details

Remember the drop event target position and move the items once they become available. This requires us to allow moving while no drag image is being shown. Otherwise, we listen to the copy job signals, which gets created by the drop job. This allows us to map target filenames in their final form, i.e. after the user potentially renamed the files to handle conflicts, to some desired visual position. To stay on the safe side, we also periodically cleanup the mapping after an idle timeout of 10s. This ensures we don't grow the mapping with stale items. This is required to handle errors in the file lister, or situations like overwriting an existing file which would not trigger a rowAdded signal. Overall, I'm quite happy with this approach. It seems to be quite stable and requires minimal invasive changes only. That said, in the long term we could, and should, cleanup this code to move more of the visual representation into the Positioner. That is a big change though, due to the way the Positioner is currently written. Most notably, that one reacts on rowsAboutToBeInserted which makes it impossible to query for any data of the row that gets inserted...

Remember the drop event target position and move the items once they become available. This requires us to allow moving while no drag image is being shown. Otherwise, we listen to the copy job signals, which gets created by the drop job. This allows us to map target filenames in their final form, i.e. after the user potentially renamed the files to handle conflicts, to some desired visual position. To stay on the safe side, we also periodically cleanup the mapping after an idle timeout of 10s. This ensures we don't grow the mapping with stale items. This is required to handle errors in the file lister, or situations like overwriting an existing file which would not trigger a rowAdded signal.

Remember the drop event target position and move the items once they become available. This requires us to allow moving while no drag image is being shown. Otherwise, we listen to the copy job signals, which gets created by the drop job. This allows us to map target filenames in their final form, i.e. after the user potentially renamed the files to handle conflicts, to some desired visual position. To stay on the safe side, we also periodically cleanup the mapping after an idle timeout of 10s. This ensures we don't grow the mapping with stale items. This is required to handle errors in the file lister, or situations like overwriting an existing file which would not trigger a rowAdded signal. Overall, I'm quite happy with this approach. It seems to be quite stable and requires minimal invasive changes only. That said, in the long term we could, and should, cleanup this code to move more of the visual representation into the Positioner. That is a big change though, due to the way the Positioner is currently written. Most notably, that one reacts on rowsAboutToBeInserted which makes it impossible to query for any data of the row that gets inserted...