hein added a comment.
IRC talk for posterity: [17:32] <milian> from the notes you sent mlaurent, and from what I remember form our past discussion, it is not clear to me how you envisioned (or even implemented) the mapping of drop action -> new file [17:33] <milian> first of all, what happens when you move e.g. "foo" into a (different) folder that already contains a file of that name? [17:33] <milian> the user would get the conflict dialog and either skip, or rename, the dropped file [17:33] <Sho_> that one is easy: I didn't handle that complication yet :-) [17:33] <milian> to me it looks like we will need to extend the dropjob extensively [17:33] <milian> ah ok [17:33] <Sho_> or let's put it another way, the general issue with my hack, and why it didn't get finished, was evicting the cache of expected files [17:34] <milian> right [17:34] <Sho_> similar to yours i was writing down notes about what to expect on drop, and then monitoring kio jobs coming in [17:34] <milian> that could be hacked around with some timers as you suggested, but it would leave my situation above open [17:34] <milian> i.e. a renamed file would then suddenly appear at the first empty spot [17:34] <milian> not at the dropped spot [17:34] <Sho_> yep, and my gut feeling is always "if you write a timer in expectation of something happening later you're most likely doing it wrong and/or being lazy" [17:35] <milian> ++ [17:35] <Sho_> a delay-type QTimer is basically always a red flag f or me [17:35] <milian> exactly my thoughts [17:35] <Sho_> which is why I was very unhappy with it [17:35] <milian> so what I'm thinking about right now is to extend the dropjob API considerably [17:35] <milian> I haven't looked at its internals yet, but I hope it knows about everything that is going on internally [17:35] <Sho_> extending DropJob and having some global D-Bus stuff (similar to the way that kioslaves signal file rename transactions to file managers) would be a lot better [17:35] <fvogt> Hm, kwin_wayland is currently FUBAR, segfaults instantly on openQA [17:36] <Sho_> so I like that you think in that direction as well [17:36] <milian> it already contains a signal about a copied file, but that signal misses information about the dragged file [17:36] <Sho_> one interesting thought: did kdesktop handle this? [17:36] <milian> if that would be there, one could do a good mapping [17:36] <Sho_> if so, how? [17:36] <Sho_> (the old qwidget desktop in kde2/3) [17:36] <Sho_> kio was around then, so maybe it had ideas [17:36] <milian> while I did use kde3, I never looked at that code. I'll ask dfaure and others who might remember [17:37] <Sho_> kio was more or less created for that icon view, so ... [17:37] <milian> ok, but that is already the biggest questions I had, so thanks for confirming my thoughts (or fears?) [17:37] <Sho_> maybe they knew what they wanted todo and how REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D8598 To: mwolff, hein, amantia Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
