IO: Add support for multiple drag-n-drop files #107230
|
@ -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
|
||||
/**
|
||||
* 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
Julian Eisel
commented
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);
|
||||
|
||||
|
|
|
@ -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;
|
||||
};
|
||||
|
|
|
@ -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
Bastien Montagne
commented
Is there a reason for using string extension instead of the (already computed) 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
`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
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.
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
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
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.
|
||||
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
Julian Eisel
commented
Same, remove Same, remove `const` from return type.
|
||||
{
|
||||
if (drag->type != WM_DRAG_PATH) {
|
||||
return blender::Span<std::string>();
|
||||
guishe marked this conversation as resolved
Outdated
Bastien Montagne
commented
`return nullptr;`
|
||||
|
|
|
@ -15,7 +15,7 @@
|
|||
|
||||
namespace blender::tests {
|
||||
|
||||
TEST(wm_dragdrop, create)
|
||||
TEST(wm_drag, wmDragPath)
|
||||
guishe marked this conversation as resolved
Outdated
Julian Eisel
commented
Should mention that this is testing for paths specifically. Suggest something like Should mention that this is testing for paths specifically. Suggest something like `TEST(wm_drag, wmDragPath)`.
|
||||
{
|
||||
{
|
||||
/**
|
||||
|
|
|
@ -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
Julian Eisel
commented
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
Julian Eisel
commented
Redundant Redundant `break` since there's a break a few lines below.
|
||||
|
|
This is returned by value, so
const
for the return type doesn't make sense (some static analyzers will warn I think).