Details

This is a patch for T61412 which introduces a soft-delete for the file explorer on Windows. The IFileOperation interface is used for Windows 8 and later, older Windows versions use the legacy interface. The patch includes code from D4579@Kris (Metricity) who implemented the function using the legacy API, is used for older Windows versions. I have tested the patch on Windows 10 using long paths, including Umlaute in filenames.

I think it's fine to call CoInitializeEx multiple times, the main issue is ensuring we don't call it with different values. I'm not sure there is a good way to automatically ensure it's not called with different values. If someone adds another call to CoInitialize in the future I would hope they read the documentation and then search for any similar calls in the code and verify it's ok.

I think it's fine to call CoInitializeEx multiple times, the main issue is ensuring we don't call it with different values. I'm not sure there is a good way to automatically ensure it's not called with different values. If someone adds another call to CoInitialize in the future I would hope they read the documentation and then search for any similar calls in the code and verify it's ok.

Allright lets keep it as is then, also keep the call to CoUninitialize since they need to be balanced.

The COM handling seems to be a bit difficult with the CoInitializeEx() CoUninitialize(). As per the documentation I'm not exactly sure what they do on CoUnitialize that requires it to be called before closing the application (and not sooner). I'm not sure how we could satisfy this besides moving them to Blender's startup/exit code. Perhaps using the old interface is the better solution for now, if that causes too much of an headache.

@LazyDodo (LazyDodo) That's what I thought. I wish they would properly document their API and give reason as to why certain recommendation are made (or even whether that is mandatory or a recommendation). I'll do some tests with the backward compatible flags and if some others should be included as well, like FOF_WANTNUKEWARNING. It would be great if someone could test this on Vista, just in case something behaves differently.

I would like to implement support for $topdir, but in case (1) and (2) fail (see spec) refuse to trash. This means we can simply use rename since we don't move files over across devices. This makes the code simpler and doesn't require reimplementing mv.

I think the complexity is manageable, but that is your decision. The problem that I see with the Electron approach is finding out what desktop environment we're on (which implies what CLI utility can be used). Does Blender already have an equivalent of libgtkui::GetDesktopName?

I will not accept a patch with an implementation of the trash specification, especially not a custom implementation. Correctly handling all the errors and corner cases is hard, we should use a mature implementation rather than spend time on this ourselves.

We should just use gio and similar, then we can make the implementation very small and reliable.

@Robert Guetzkow (rjg) I think so. If you can make sure that it only affects Windows, or can also add Mac/Linux support, then I can't see why we shouldn't still add this. Preferably we should try to add support for all three at once I think.