IO: Add support for multiple drag-n-drop files #107230
|
@ -768,29 +768,29 @@ const ListBase *WM_drag_asset_list_get(const wmDrag *drag)
|
||||||
return &drag->asset_items;
|
return &drag->asset_items;
|
||||||
brecht marked this conversation as resolved
Outdated
|
|||||||
}
|
}
|
||||||
|
|
||||||
guishe marked this conversation as resolved
Outdated
Julian Eisel
commented
This is just 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.
|
|||||||
wmDragPath *WM_drag_create_path_data(blender::Span<const char *> _paths)
|
wmDragPath *WM_drag_create_path_data(blender::Span<const char *> paths)
|
||||||
{
|
{
|
||||||
const char *extension = BLI_path_extension(_paths[0]);
|
const char *extension = BLI_path_extension(paths[0]);
|
||||||
blender::Vector<std::string> paths;
|
blender::Vector<std::string> filtered_paths;
|
||||||
for (auto path : _paths) {
|
for (auto path : paths) {
|
||||||
const char *test_ext = BLI_path_extension(path);
|
const char *test_ext = BLI_path_extension(path);
|
||||||
if (extension == test_ext || (extension && test_ext && STREQ(extension, test_ext))) {
|
if (extension == test_ext || (extension && test_ext && STREQ(extension, test_ext))) {
|
||||||
guishe marked this conversation as resolved
Outdated
Bastien Montagne
commented
There is no reason to use C-strings here. 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
No final point in our UI strings: No final point in our UI strings: `"Dragging {} files"`
|
|||||||
paths.append(path);
|
filtered_paths.append(path);
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
const char *tooltip = _paths[0];
|
const char *tooltip = paths[0];
|
||||||
char tooltip_buffer[256];
|
char tooltip_buffer[256];
|
||||||
if (_paths.size() == 1) {
|
if (filtered_paths.size() > 1) {
|
||||||
BLI_snprintf(tooltip_buffer,
|
BLI_snprintf(tooltip_buffer,
|
||||||
ARRAY_SIZE(tooltip_buffer),
|
ARRAY_SIZE(tooltip_buffer),
|
||||||
TIP_("Dragging %d %s files."),
|
TIP_("Dragging %d %s files."),
|
||||||
paths.size(),
|
filtered_paths.size(),
|
||||||
extension ? extension : TIP_("Folder"));
|
extension ? extension : TIP_("Folder"));
|
||||||
tooltip = tooltip_buffer;
|
tooltip = tooltip_buffer;
|
||||||
}
|
}
|
||||||
|
|
||||||
wmDragPath *path_data = MEM_new<wmDragPath>(
|
wmDragPath *path_data = MEM_new<wmDragPath>(
|
||||||
"wmDragPath", paths, tooltip, ED_path_extension_type(_paths[0]));
|
"wmDragPath", filtered_paths, tooltip, ED_path_extension_type(paths[0]));
|
||||||
|
|
||||||
return path_data;
|
return path_data;
|
||||||
}
|
}
|
||||||
|
|
Loading…
Reference in New Issue
Is there a reason for using string extension instead of the (already computed)
file_type
here (and then comparing to the result ofED_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.
ED_path_extension_type
is only for file types that Blender natively supports, while this system is meant to work for arbitrary add-ons.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 thisfile_type
will just you describe the first path.Ah yes, makes sense, better not do any filtering here then indeed.