blender
/
blender
134
399
Fork 582
Code Issues 6.3k Pull Requests 757 Projects 19 Wiki Activity

IO: Add support for multiple drag-n-drop files #107230

Merged
Brecht Van Lommel merged 20 commits from guishe/blender:dragndrop-files into main 2023-12-12 18:46:22 +01:00
Conversation 9 Commits 20 Files Changed 16 +15 -14
2 changed files with 15 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 1ae824ba8f - Show all commits

10
source/blender/windowmanager/WM_types.hh
View File

@ -1173,15 +1173,11 @@ struct wmDragAssetListItem {
};
struct wmDragPath {
const blender::Vector<std::string> paths;
blender::Vector<std::string> paths;
/* Note that even though the enum type uses bit-flags, this should never have multiple type-bits
* set, so `ELEM()` like comparison is possible. */
const int file_type; /* eFileSel_File_Types */
const std::string tooltip;
wmDragPath(const blender::Vector<std::string> &paths, const std::string &tooltip, int file_type)
: paths(std::move(paths)), file_type(file_type), tooltip(tooltip)
{
}
int file_type; /* eFileSel_File_Types */
std::string tooltip;
};
struct wmDragGreasePencilLayer {

19
source/blender/windowmanager/intern/wm_dragdrop.cc
View File

@ -761,27 +761,32 @@ const ListBase *WM_drag_asset_list_get(const wmDrag *drag)
wmDragPath *WM_drag_create_path_data(blender::Span<const char *> paths)
{
wmDragPath *path_data = MEM_new<wmDragPath>("wmDragPath");
path_data->file_type = ED_path_extension_type(paths[0]);
const char *extension = BLI_path_extension(paths[0]);
brecht marked this conversation as resolved Outdated
Bastien Montagne commented 2023-11-07 16:11:29 +01:00
Outdated
Review
Copy Link

Is there a reason for using string extension instead of the (already computed) file_type here (and then comparing to the result of ED_path_extension_type for all other paths in the loop below)?

If yes, should be documented in a comment.

Current approach would also 'fail' (filter out valid paths) e.g. in case of paths to a mix of JPG and PNG images. Or paths containing several USD files with different extensions.

Is there a reason for using string extension instead of the (already computed) `file_type` here (and then comparing to the result of `ED_path_extension_type` for all other paths in the loop below)? If yes, should be documented in a comment. Current approach would also 'fail' (filter out valid paths) e.g. in case of paths to a mix of JPG and PNG images. Or paths containing several USD files with different extensions.
Brecht Van Lommel commented 2023-11-07 16:43:08 +01:00
Outdated
Review
Copy Link

ED_path_extension_type is only for file types that Blender natively supports, while this system is meant to work for arbitrary add-ons.

`ED_path_extension_type` is only for file types that Blender natively supports, while this system is meant to work for arbitrary add-ons.
Guillermo Venegas commented 2023-11-07 19:39:42 +01:00
Outdated
Review
Copy Link

Initially I had the idea of just the one extension for file handler, but since file handlers could have a list of files they can take, here we can copy all and then see which ones are useful for the file handlers.

path_data->file_type would only be used internally with the first file, and since these changes don't change the behavior I think it's safe to keep it and collect all the file paths, I'll leave a note that this file_type will just you describe the first path.

Initially I had the idea of just the one extension for file handler, but since file handlers could have a list of files they can take, here we can copy all and then see which ones are useful for the file handlers. `path_data->file_type` would only be used internally with the first file, and since these changes don't change the behavior I think it's safe to keep it and collect all the file paths, I'll leave a note that this `file_type` will just you describe the first path.
Bastien Montagne commented 2023-11-08 18:27:50 +01:00
Outdated
Review
Copy Link

Ah yes, makes sense, better not do any filtering here then indeed.

Ah yes, makes sense, better not do any filtering here then indeed.
blender::Vector<std::string> filtered_paths;
for (auto path : paths) {
guishe marked this conversation as resolved Outdated
Julian Eisel commented 2023-11-22 12:28:59 +01:00
Outdated
Review
Copy Link

This is just const char* isn't it? In that case auto just hides type information with no real benefit, prefer not using it in such cases.

This is just `const char*` isn't it? In that case `auto` just hides type information with no real benefit, prefer not using it in such cases.
const char *test_ext = BLI_path_extension(path);
if (extension == test_ext || (extension && test_ext && STREQ(extension, test_ext))) {
filtered_paths.append(path);
path_data->paths.append(path);
}
}
const char *tooltip = paths[0];
const char *tooltip = path_data->paths[0].c_str();
guishe marked this conversation as resolved Outdated
Bastien Montagne commented 2023-11-07 16:32:22 +01:00
Outdated
Review
Copy Link

There is no reason to use C-strings here. std::string and fmt::format (extern library we are using since we are not yet on C++20) should be even easier to use.

There is no reason to use C-strings here. `std::string` and `fmt::format` (extern library we are using since we are not yet on C++20) should be even easier to use.
Bastien Montagne commented 2023-11-08 18:24:09 +01:00
Review
Copy Link

No final point in our UI strings: "Dragging {} files"

No final point in our UI strings: `"Dragging {} files"`
char tooltip_buffer[256];
if (filtered_paths.size() > 1) {
if (path_data->paths.size() > 1) {
BLI_snprintf(tooltip_buffer,
ARRAY_SIZE(tooltip_buffer),
TIP_("Dragging %d %s files."),
filtered_paths.size(),
path_data->paths.size(),
extension ? extension : TIP_("Folder"));
tooltip = tooltip_buffer;
}
wmDragPath *path_data = MEM_new<wmDragPath>(
"wmDragPath", filtered_paths, tooltip, ED_path_extension_type(paths[0]));
path_data->tooltip = tooltip;
return path_data;
}