godotengine
Windows: Fix dragging and dropping files from compressed files into editor
Fixes #97128.
Use case described by @Maran23 in https://github.com/godotengine/godot/issues/97128#issuecomment-2357090873 still doesn't work. I can look into it later.
Good job, and congratulations on your first commit! I tested this and it does appear to work in regards to the issue I raised with 7zip. I'll approve this for now, but would you mind squashing the commits from this PR into a single commit? We generally prefer that convention when merging.
Thank you! I have squashed the commits.
Seems to be working as expected.
Use case described by @Maran23 in #97128 (comment) still doesn't work. I can look into it later.
This likely requires handling CFSTR_FILECONTENTS and CFSTR_FILEDESCRIPTOR in addition to
CF_HDROP.
Added handling of CFSTR_FILEDESCRIPTOR and CFSTR_FILECONTENTS as you have suggested. Now drag-and-drop from inside the .zip file from Windows Explorer also works. Also I tested the same case with Total Commander and it works as well.
However, this time I had to do a bit of filesystem manipulations and couldn't find some functinality in Godot's source code. These are: joining filepaths with correct OS separator, creating temporary directory with random name, creating all subdirectories for a path and recursively removing directory with it's contents. For now I have written quick & dirty implementations of these, which are not general purpose, but happen to work here. So I would appreciate it if someone pointed me to the relevant existing functionality. Or if it doesn't exist, it probably should be added (maybe in a separate PR?) for general use.
These are: joining filepaths with correct OS separator, creating temporary directory with random name, creating all subdirectories for a path and recursively removing directory with it's contents.
There's DirAccess::erase_contents_recursive, DirAccess::make_dir_recursive and String::path_join (like all other public Godot IO functions, these use / separator, usually conversion is done internally right before passing path to the system API and never exposed to the user, see fix_path in OS_Windows).
https://github.com/godotengine/godot/blob/b3bcb2dc14691f7729984128dca26a844f662fa1/platform/windows/os_windows.cpp#L93-L108
Do we want to wait and try to solve that edge-case, or is this ready to merge now in your eyes?
Do we want to wait and try to solve that edge-case, or is this ready to merge now in your eyes?
I think it's okay to merge. This edge case doesn't cause issues on my system (Windows 10), so I can't debug @Calinou's problem on Windows 11. I believe fixing it should be in a separate PR done by someone else.