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
5 changed files with 8 additions and 11 deletions
Showing only changes of commit 21a07782fb - Show all commits

View File

@ -1427,11 +1427,11 @@ const char *WM_drag_get_item_name(wmDrag *drag);
*/
wmDragPath *WM_drag_create_path_data(blender::Span<const char *> paths);
const char *WM_drag_get_single_path(const wmDrag *drag);
const blender::Span<std::string> WM_drag_get_paths(const wmDrag *drag);
blender::Span<std::string> WM_drag_get_paths(const wmDrag *drag);
guishe marked this conversation as resolved Outdated

This is returned by value, so const for the return type doesn't make sense (some static analyzers will warn I think).

This is returned by value, so `const` for the return type doesn't make sense (some static analyzers will warn I think).
/**
* Note that even though the enum return type uses bit-flags, this should never have multiple
* type-bits set, so `ELEM()` like comparison is possible. For internal use only, and only
* indicates the file type of first path in `wmDragPath.paths`.
* type-bits set, so `ELEM()` like comparison is possible. Only indicates the file type of first
guishe marked this conversation as resolved Outdated

The "For internal use only" part doesn't make sense to me, this is a public API.

The "For internal use only" part doesn't make sense to me, this is a public API.
* path in `wmDragPath.paths`.
*/
int /* eFileSel_File_Types */ WM_drag_get_path_file_type(const wmDrag *drag);

View File

@ -1175,8 +1175,8 @@ struct wmDragAssetListItem {
struct wmDragPath {
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. For internal use only, and only indicates the
* file type of first path in `wmDragPath.paths`. */
* set, so `ELEM()` like comparison is possible. Only indicates the file type of first path in
* `wmDragPath.paths`. */
int file_type; /* eFileSel_File_Types */
std::string tooltip;
};

View File

@ -767,7 +767,7 @@ wmDragPath *WM_drag_create_path_data(blender::Span<const char *> paths)
path_data->file_type = ED_path_extension_type(paths[0]);
brecht marked this conversation as resolved Outdated

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.

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.

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.

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

Ah yes, makes sense, better not do any filtering here then indeed.
for (auto path : paths) {
for (const char *path : paths) {
guishe marked this conversation as resolved Outdated

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.
path_data->paths.append(path);
}
@ -797,7 +797,7 @@ const char *WM_drag_get_single_path(const wmDrag *drag)
return path_data->paths[0].c_str();
}
const blender::Span<std::string> WM_drag_get_paths(const wmDrag *drag)
blender::Span<std::string> WM_drag_get_paths(const wmDrag *drag)
guishe marked this conversation as resolved Outdated

Same, remove const from return type.

Same, remove `const` from return type.
{
if (drag->type != WM_DRAG_PATH) {
return blender::Span<std::string>();
guishe marked this conversation as resolved Outdated

return nullptr;

`return nullptr;`

View File

@ -15,7 +15,7 @@
namespace blender::tests {
TEST(wm_dragdrop, create)
TEST(wm_drag, wmDragPath)
guishe marked this conversation as resolved Outdated

Should mention that this is testing for paths specifically. Suggest something like TEST(wm_drag, wmDragPath).

Should mention that this is testing for paths specifically. Suggest something like `TEST(wm_drag, wmDragPath)`.
{
{
/**

View File

@ -65,8 +65,6 @@
#include "ED_scene.hh"
#include "ED_screen.hh"
#include <fmt/format.h>
#include "IMB_imbuf.h"
guishe marked this conversation as resolved Outdated

Doesn't seem to be needed.

Doesn't seem to be needed.
#include "IMB_imbuf_types.h"
@ -1583,7 +1581,6 @@ static bool ghost_event_proc(GHOST_EventHandle evt, GHOST_TUserDataPtr C_void_pt
blender::Span((char **)stra->strings, stra->count));
WM_event_start_drag(C, icon, WM_DRAG_PATH, path_data, 0.0, WM_DRAG_NOP);
/* Void pointer should point to string, it makes a copy. */
break;
}
}
guishe marked this conversation as resolved Outdated

Redundant break since there's a break a few lines below.

Redundant `break` since there's a break a few lines below.