<table><tr><td style="">hein added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D8598" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>IRC talk for posterity:</p>

<p>[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<br />
[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?<br />
[17:33] <milian> the user would get the conflict dialog and either skip, or rename, the dropped file<br />
[17:33] <Sho_> that one is easy: I didn't handle that complication yet :-)<br />
[17:33] <milian> to me it looks like we will need to extend the dropjob extensively<br />
[17:33] <milian> ah ok<br />
[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<br />
[17:34] <milian> right<br />
[17:34] <Sho_> similar to yours i was writing down notes about what to expect on drop, and then monitoring kio jobs coming in<br />
[17:34] <milian> that could be hacked around with some timers as you suggested, but it would leave my situation above open<br />
[17:34] <milian> i.e. a renamed file would then suddenly appear at the first empty spot<br />
[17:34] <milian> not at the dropped spot<br />
[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"<br />
[17:35] <milian> ++<br />
[17:35] <Sho_> a delay-type QTimer is basically always a red flag f or me<br />
[17:35] <milian> exactly my thoughts<br />
[17:35] <Sho_> which is why I was very unhappy with it<br />
[17:35] <milian> so what I'm thinking about right now is to extend the dropjob API considerably<br />
[17:35] <milian> I haven't looked at its internals yet, but I hope it knows about everything that is going on internally<br />
[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<br />
[17:35] <fvogt> Hm, kwin_wayland is currently FUBAR, segfaults instantly on openQA<br />
[17:36] <Sho_> so I like that you think in that direction as well<br />
[17:36] <milian> it already contains a signal about a copied file, but that signal misses information about the dragged file<br />
[17:36] <Sho_> one interesting thought: did kdesktop handle this?<br />
[17:36] <milian> if that would be there, one could do a good mapping<br />
[17:36] <Sho_> if so, how?<br />
[17:36] <Sho_> (the old qwidget desktop in kde2/3)<br />
[17:36] <Sho_> kio was around then, so maybe it had ideas<br />
[17:36] <milian> while I did use kde3, I never looked at that code. I'll ask dfaure and others who might remember<br />
[17:37] <Sho_> kio was more or less created for that icon view, so ...<br />
[17:37] <milian> ok, but that is already the biggest questions I had, so thanks for confirming my thoughts (or fears?)<br />
[17:37] <Sho_> maybe they knew what they wanted todo and how</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R119 Plasma Desktop</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D8598" rel="noreferrer">https://phabricator.kde.org/D8598</a></div></div><br /><div><strong>To: </strong>mwolff, hein, amantia<br /><strong>Cc: </strong>plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart<br /></div>