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 URLs 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...
Differential Revision: https://phabricator.kde.org/D8598