As in the topic. I could probably split this a bit if you insist, but it got so damm entangled..
this depends on pr #1530
changed: remove unused IFile callback from GUIWindowFileManager
added: listen to GUI_MSG_UPDATE in GUIWindowFileManager
better split now and no longer depends on #1530
Looks good to me. A few functions could be const (You asked for it by changing one that wasn't related...)
added: comparison operator to CFileOperationJob
refactor: split off action to string into GetActionString
changed: background file manager operations
added: possibility to cancel file manager operations
hah, as if i'd ever do such a thing ;) put it in the correct context now + made the new functions const.
no other concerns?
If you are interested in a user opinion: I would like it even more if it would copy or move files one after another with any kind of queue and not parallel.
it's sorta what it does. it does two user-initiated operations in parallel. an operation can be copying n files or n dirs or whatever.
Oh, looks like I was not precise enough - sorry.
When I start copying file A and then start copying file B, both copy-jobs are done at the same time (and the progress window switches between the jobs).
i got you. if, however, you mark file a and file b and hit copy, they will be copied in sequence. doing it all in sequence is trivial, that's just removing the 2 thread slots. but imo this is better.