D8598: WIP: position files at drop target position in folder

[Eike Hein]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20171102/fa477cd3/attachment.html>