blender
/
blender
131
398
Fork 577
Code Issues 6.2k Pull Requests 743 Projects 19 Wiki Activity

Add support to Drag and Drop to FileHandlers #116047

Merged
Jesse Yurkovich merged 16 commits from guishe/blender:fh-dnd-support into main 2024-01-06 03:51:57 +01:00
Conversation 12 Commits 16 Files Changed 10 +605
Guillermo Venegas commented 2023-12-11 17:34:27 +01:00
Contributor
Copy Link

Added support to Drag and Drop to file handlers, part of #111242.

If file handlers are registered with an import operator they
can now be invoked with drag and drop path data.

To make it works, import operatos must have declared a
filepath string property if supports handling one file
at the time, if they support multiple files it needs a
directory string property and a files collection properties.

Multiple FileHandlers could be valid for handle drop path data,
when this happens a menu is shown so user can choose what to do
with the drop data.

If the operator only supports to handle one file
at the time, the operator should have a
FILE_PATH StringProperty called filepath

filepath: StringProperty(subtype='FILE_PATH')

If the operator supports multiple files, the operator should
have a DIR_PATH StringProperty called directory
and a OperatorFileListElement CollectionProperty called files

directory: StringProperty(subtype='DIR_PATH')
files: CollectionProperty(type=OperatorFileListElement)
Some examples of file handlers for testing 
import bpy

class WM_FH_alembic(bpy.types.FileHandler):
    bl_idname = "WM_FH_alembic"
    bl_label = "Alembic file handler"
    bl_import_operator = "WM_OT_alembic_import"
    bl_file_extensions = ".abc"

    @classmethod
    def poll_drop(cls, context):
        return context.area.type == "VIEW_3D"


class WM_FH_collada(bpy.types.FileHandler):
    bl_idname = "WM_FH_collada"
    bl_label = "COLLADA file handler"
    bl_import_operator = "WM_OT_collada_import"
    bl_file_extensions = ".dae"

    @classmethod
    def poll_drop(cls, context):
        return context.area.type == "VIEW_3D"


class WM_FH_gpencil(bpy.types.FileHandler):
    bl_idname = "WM_FH_gpencil"
    bl_label = "gpencil file handler"
    bl_import_operator = "WM_OT_gpencil_import_svg"
    bl_file_extensions = ".svg"

    @classmethod
    def poll_drop(cls, context):
        return context.area.type == "VIEW_3D"


class WM_FH_obj(bpy.types.FileHandler):
    bl_idname = "WM_FH_obj"
    bl_label = "Wavefront OBJ file handler"
    bl_import_operator = "WM_OT_obj_import"
    bl_file_extensions = ".obj"

    @classmethod
    def poll_drop(cls, context):
        return context.area.type == "VIEW_3D"


class WM_FH_ply(bpy.types.FileHandler):
    bl_idname = "WM_FH_ply"
    bl_label = "PLY file handler"
    bl_import_operator = "WM_OT_ply_import"
    bl_file_extensions = ".ply"

    @classmethod
    def poll_drop(cls, context):
        return context.area.type == "VIEW_3D"


class WM_FH_stl(bpy.types.FileHandler):
    bl_idname = "WM_FH_stl"
    bl_label = "STL (experimental) file handler"
    bl_import_operator = "WM_OT_stl_import"
    bl_file_extensions = ".stl"

    @classmethod
    def poll_drop(cls, context):
        return context.area.type == "VIEW_3D"


class WM_FH_import_mesh_stl(bpy.types.FileHandler):
    bl_idname = "WM_FH_import_mesh_stl"
    bl_label = "STL file handler"
    bl_import_operator = "import_mesh.stl"
    bl_file_extensions = ".stl"

    @classmethod
    def poll_drop(cls, context):
        return context.area.type == "VIEW_3D"


class WM_FH_usd(bpy.types.FileHandler):
    bl_idname = "WM_FH_usd"
    bl_label = "USD file handler"
    bl_import_operator = "WM_OT_usd_import"
    bl_file_extensions = ".usd;.usda;.usdc;.usdz"

    @classmethod
    def poll_drop(cls, context):
        return context.area.type == "VIEW_3D"
    
classes = (

    WM_FH_alembic,
    WM_FH_collada,
    WM_FH_gpencil,
    WM_FH_obj,
    WM_FH_ply,
    WM_FH_stl,
    WM_FH_import_mesh_stl,
    WM_FH_usd,

)

def register():
    for cls in classes:
        bpy.utils.register_class(cls)


def unregister():
    for cls in classes:
        bpy.utils.unregister_class(cls)

if __name__ == "__main__":
    register()
Added support to Drag and Drop to file handlers, part of https://projects.blender.org/blender/blender/pulls/111242. If file handlers are registered with an import operator they can now be invoked with drag and drop path data. To make it works, import `operatos` must have declared a `filepath` string property if supports handling one file at the time, if they support multiple files it needs a `directory` string property and a `files` collection properties. Multiple `FileHandlers` could be valid for handle drop path data, when this happens a menu is shown so user can choose what to do with the drop data. ------ If the operator only supports to handle one file at the time, the operator should have a `FILE_PATH` `StringProperty` called `filepath` filepath: StringProperty(subtype='FILE_PATH') If the operator supports multiple files, the operator should have a `DIR_PATH` `StringProperty` called `directory` and a `OperatorFileListElement` `CollectionProperty` called `files` directory: StringProperty(subtype='DIR_PATH') files: CollectionProperty(type=OperatorFileListElement) <details> <summary>Some examples of file handlers for testing</summary> ```python import bpy class WM_FH_alembic(bpy.types.FileHandler): bl_idname = "WM_FH_alembic" bl_label = "Alembic file handler" bl_import_operator = "WM_OT_alembic_import" bl_file_extensions = ".abc" @classmethod def poll_drop(cls, context): return context.area.type == "VIEW_3D" class WM_FH_collada(bpy.types.FileHandler): bl_idname = "WM_FH_collada" bl_label = "COLLADA file handler" bl_import_operator = "WM_OT_collada_import" bl_file_extensions = ".dae" @classmethod def poll_drop(cls, context): return context.area.type == "VIEW_3D" class WM_FH_gpencil(bpy.types.FileHandler): bl_idname = "WM_FH_gpencil" bl_label = "gpencil file handler" bl_import_operator = "WM_OT_gpencil_import_svg" bl_file_extensions = ".svg" @classmethod def poll_drop(cls, context): return context.area.type == "VIEW_3D" class WM_FH_obj(bpy.types.FileHandler): bl_idname = "WM_FH_obj" bl_label = "Wavefront OBJ file handler" bl_import_operator = "WM_OT_obj_import" bl_file_extensions = ".obj" @classmethod def poll_drop(cls, context): return context.area.type == "VIEW_3D" class WM_FH_ply(bpy.types.FileHandler): bl_idname = "WM_FH_ply" bl_label = "PLY file handler" bl_import_operator = "WM_OT_ply_import" bl_file_extensions = ".ply" @classmethod def poll_drop(cls, context): return context.area.type == "VIEW_3D" class WM_FH_stl(bpy.types.FileHandler): bl_idname = "WM_FH_stl" bl_label = "STL (experimental) file handler" bl_import_operator = "WM_OT_stl_import" bl_file_extensions = ".stl" @classmethod def poll_drop(cls, context): return context.area.type == "VIEW_3D" class WM_FH_import_mesh_stl(bpy.types.FileHandler): bl_idname = "WM_FH_import_mesh_stl" bl_label = "STL file handler" bl_import_operator = "import_mesh.stl" bl_file_extensions = ".stl" @classmethod def poll_drop(cls, context): return context.area.type == "VIEW_3D" class WM_FH_usd(bpy.types.FileHandler): bl_idname = "WM_FH_usd" bl_label = "USD file handler" bl_import_operator = "WM_OT_usd_import" bl_file_extensions = ".usd;.usda;.usdc;.usdz" @classmethod def poll_drop(cls, context): return context.area.type == "VIEW_3D" classes = ( WM_FH_alembic, WM_FH_collada, WM_FH_gpencil, WM_FH_obj, WM_FH_ply, WM_FH_stl, WM_FH_import_mesh_stl, WM_FH_usd, ) def register(): for cls in classes: bpy.utils.register_class(cls) def unregister(): for cls in classes: bpy.utils.unregister_class(cls) if __name__ == "__main__": register() ``` </details>
👍 1
Guillermo Venegas added 1 commit 2023-12-11 17:34:36 +01:00
Guillermo Venegas changed title from Add support to Drag and Drop to file handlers to Add support to Drag and Drop to FileHandlers 2023-12-11 17:34:52 +01:00
Brecht Van Lommel requested review from Jesse Yurkovich 2023-12-12 15:17:56 +01:00
Brecht Van Lommel requested review from Julian Eisel 2023-12-12 15:18:05 +01:00
Brecht Van Lommel commented 2023-12-12 15:31:36 +01:00
Owner
Copy Link

Can you add a doc/python_api/examples/bpy.types.FileHandler.py with a simple example operator and file handler? With code comments explaining the required operator properties.

Can you add a `doc/python_api/examples/bpy.types.FileHandler.py` with a simple example operator and file handler? With code comments explaining the required operator properties.
Guillermo Venegas added 2 commits 2023-12-12 20:23:13 +01:00
Guillermo Venegas added 1 commit 2023-12-12 20:34:18 +01:00
Jesse Yurkovich requested changes 2023-12-14 10:35:49 +01:00
Jesse Yurkovich left a comment
Member
Copy Link

Generally works alright given your two examples here. Just a few comments from what I've seen so far.

Generally works alright given your two examples here. Just a few comments from what I've seen so far.
doc/python_api/examples/bpy.types.FileHandler.1.py Outdated
@ -0,0 +49,4 @@
return {'RUNNING_MODAL'}
class Curve_FH_text_import(bpy.types.FileHandler):
Jesse Yurkovich commented 2023-12-14 10:10:28 +01:00
Member
Copy Link

Should be CURVE_FH_text_import (here and a few other places etc.) to prevent "Warning: 'Curve_FH_text_import' doesn't have upper case alpha-numeric prefix"

Should be `CURVE_FH_text_import` (here and a few other places etc.) to prevent "Warning: 'Curve_FH_text_import' doesn't have upper case alpha-numeric prefix"
guishe marked this conversation as resolved
doc/python_api/examples/bpy.types.FileHandler.2.py Outdated
@ -0,0 +64,4 @@
return {'RUNNING_MODAL'}
class Shader_FH_script_import(bpy.types.FileHandler):
Jesse Yurkovich commented 2023-12-14 10:11:05 +01:00
Member
Copy Link

Adjust the casing of the name of this FileHandler too.

Adjust the casing of the name of this FileHandler too.
guishe marked this conversation as resolved
source/blender/blenkernel/CMakeLists.txt Outdated
@ -21,6 +21,7 @@ set(INC
../sequencer
../shader_fx
../simulation
../windowmanager
Jesse Yurkovich commented 2023-12-14 08:59:54 +01:00
Member
Copy Link

This creates a circular dependency as windowmanager also depends on blenkernel. There's many such circular refs already but I would hate to add another one. I think I would keep the use of the WM API to just the io_drop_import_file.cc file to side step the organizational issue.

This creates a circular dependency as windowmanager also depends on blenkernel. There's many such circular refs already but I would hate to add another one. I think I would keep the use of the WM API to just the `io_drop_import_file.cc` file to side step the organizational issue.
guishe marked this conversation as resolved
source/blender/blenkernel/intern/file_handler.cc Outdated
@ -60,0 +141,4 @@
return WM_operatortype_find(import_operator, quiet);
}
static const char *property_type_str(PropertyType prop_type)
Jesse Yurkovich commented 2023-12-14 10:30:49 +01:00
Member
Copy Link

Feels a bit wrong for something like this to be defined here rather than under a RNA_ api. Will let others comment further on it if they wish though.

Feels a bit wrong for something like this to be defined here rather than under a RNA_ api. Will let others comment further on it if they wish though.
Guillermo Venegas commented 2023-12-14 21:05:24 +01:00
Author
Contributor
Copy Link

Moved to rna_access
I found that this can prevent a crash in the file browser

Moved to `rna_access` I found that this can prevent a crash in the file browser
👍 1
brecht marked this conversation as resolved
source/blender/blenkernel/intern/file_handler.cc Outdated
@ -60,0 +245,4 @@
{
BLI_assert(get_import_operator());
PointerRNA props;
wmOperatorType *op = get_import_operator();
Jesse Yurkovich commented 2023-12-14 10:18:17 +01:00
Member
Copy Link

By convention use ot instead of op.

By convention use `ot` instead of op.
guishe marked this conversation as resolved
source/blender/blenkernel/intern/file_handler.cc Outdated
@ -60,0 +283,4 @@
"' files : CollectionProperty(type = OperatorFileListElement)'"),
idname,
op->idname);
CLOG_WARN(&FH_LOG, message.c_str());
Jesse Yurkovich commented 2023-12-14 10:04:12 +01:00
Member
Copy Link

I definitely appreciate messages that explain the actual problem :) Generally though, to prevent "documentation" from being in more than one place, I would instead direct the user to the API docs rather than explaining the single/multi file difference here. Maybe just indicate that expected properties were not found and see the api documentation for details. What does everyone think about that?

I definitely appreciate messages that explain the actual problem :) Generally though, to prevent "documentation" from being in more than one place, I would instead direct the user to the API docs rather than explaining the single/multi file difference here. Maybe just indicate that expected properties were not found and see the api documentation for details. What does everyone think about that?
Brecht Van Lommel commented 2023-12-18 15:07:15 +01:00
Owner
Copy Link

Sounds good to me. Something like:

Expected operator properties filepath or files and directory not found. Refer to FileHandler documentation for details.
Sounds good to me. Something like: ``` Expected operator properties filepath or files and directory not found. Refer to FileHandler documentation for details. ```
guishe marked this conversation as resolved
source/blender/editors/io/io_drop_import_file.cc Outdated
@ -0,0 +45,4 @@
static int wm_drop_import_file_exec(bContext *C, wmOperator *op)
{
auto paths = drop_import_file_paths(op);
if (paths.size() < 1) {
Jesse Yurkovich commented 2023-12-14 10:23:14 +01:00
Member
Copy Link

paths.empty()

paths.empty()
guishe marked this conversation as resolved
source/blender/editors/io/io_drop_import_file.cc Outdated
@ -0,0 +50,4 @@
}
auto file_handlers = BKE_file_handlers_poll_file_drop(C, paths);
if (file_handlers.size() == 0) {
Jesse Yurkovich commented 2023-12-14 10:23:25 +01:00
Member
Copy Link

file_handlers.empty()

file_handlers.empty()
guishe marked this conversation as resolved
source/blender/editors/io/io_drop_import_file.cc
@ -0,0 +166,4 @@
void ED_dropbox_drop_import_file()
{
ListBase *lb = WM_dropboxmap_find("Window", 0, 0);
WM_dropbox_add(lb,
Jesse Yurkovich commented 2023-12-14 09:08:42 +01:00
Member
Copy Link

Wondering if maybe we can just place this inside ED_keymap_screen as that's where the .blend file drag-drop box is added. Should use SPACE_EMPTY and RGN_TYPE_WINDOW values instead of 0 too.

Wondering if maybe we can just place this inside `ED_keymap_screen` as that's where the .blend file drag-drop box is added. Should use `SPACE_EMPTY` and `RGN_TYPE_WINDOW` values instead of 0 too.
Guillermo Venegas commented 2023-12-18 21:55:21 +01:00
Author
Contributor
Copy Link

had to duplicate drop_import_file_poll_file_handlers between io_drop_import_file.cc
and screen_ops.cc, only has the additional check for file handlers with valid operator.

this was on BKE_file_handlers_poll_file_drop but removing the wm dependency from bke dont know the right place to validate this

had to duplicate `drop_import_file_poll_file_handlers` between `io_drop_import_file.cc` and `screen_ops.cc`, only has the additional check for file handlers with valid operator. this was on `BKE_file_handlers_poll_file_drop` but removing the `wm` dependency from `bke` dont know the right place to validate this
Jesse Yurkovich commented 2023-12-19 02:37:33 +01:00
Member
Copy Link

I didn't notice that my suggestion would cause this duplication. In that case I think it's fine to keep the WM_dropbox_add/ED_dropbox_drop_import_file call inside the "io_drop_import_file.cc" file as you originally had it.

Other than that, things look fine.

I didn't notice that my suggestion would cause this duplication. In that case I think it's fine to keep the WM_dropbox_add/ED_dropbox_drop_import_file call inside the "io_drop_import_file.cc" file as you originally had it. Other than that, things look fine.
guishe marked this conversation as resolved
Guillermo Venegas added 1 commit 2023-12-14 21:02:02 +01:00
Guillermo Venegas added 2 commits 2023-12-14 21:03:48 +01:00
Guillermo Venegas added 1 commit 2023-12-15 02:19:42 +01:00
Guillermo Venegas added 2 commits 2023-12-18 21:44:09 +01:00
Guillermo Venegas added 1 commit 2023-12-18 21:46:06 +01:00
Guillermo Venegas added 2 commits 2023-12-19 15:39:42 +01:00
Guillermo Venegas added 1 commit 2023-12-19 15:41:54 +01:00
Jesse Yurkovich approved these changes 2023-12-19 22:28:34 +01:00
Jesse Yurkovich left a comment
Member
Copy Link

Looks ok from my side now.

Looks ok from my side now.
Guillermo Venegas commented 2023-12-29 18:39:21 +01:00
Author
Contributor
Copy Link

There is a way to make this even more user friendly

but that involves using a same popup for drop_to_import operator and a
selected file handler's operator and some tricks

Attached video and patch
@brecht @deadpin can take a look? maybe good enough to redo a revision

There is a way to make this even more user friendly but that involves using a same popup for `drop_to_import` operator and a selected file handler's operator and some tricks Attached video and patch @brecht @deadpin can take a look? maybe good enough to redo a revision <video src="/attachments/49700dab-1c95-4912-94a9-51091e258c2a" title="2023-12-28 21-06-53.mp4" controls></video>
file.diff
27 KiB
2023-12-28 21-06-53.mp4
6.5 MiB
❤️ 2
Brecht Van Lommel commented 2023-12-30 11:24:26 +01:00
Owner
Copy Link

I would prefer to merge the simple version of this pull request, and then refine it in a separate step.

@deadpin, do you think this could be committed since we both approved it?

As for the design in the video, I think this is getting too complex. The user already chose the files they wanted to drag, they don't have to pick some subset again on dropping. They also don't need to see or change the directory again.

The way I would present it is that, you're going to import all the files you dragged in, there's no changing that. If there are multiple file types, it could show a separate expandable panels for each, with a parent panel per file type. But still with a single button to import everything, not a separate import button for each.

I would prefer to merge the simple version of this pull request, and then refine it in a separate step. @deadpin, do you think this could be committed since we both approved it? As for the design in the video, I think this is getting too complex. The user already chose the files they wanted to drag, they don't have to pick some subset again on dropping. They also don't need to see or change the directory again. The way I would present it is that, you're going to import all the files you dragged in, there's no changing that. If there are multiple file types, it could show a separate expandable panels for each, with a parent panel per file type. But still with a single button to import everything, not a separate import button for each.
Guillermo Venegas commented 2023-12-30 12:10:06 +01:00
Author
Contributor
Copy Link

As for the design in the video, I think this is getting too complex.

I think it's more complex as the patch is now in terms of UX.

For example, if an importer only supports one file for call, the user has to drag and drop multiple times, and even worse, if the input parameters are the same, the user has to configure the settings again and again.

Also current state forces to update operators, so that they do something different if they are invoked with a path (this to avoid call a fileselect window for example)
This would requiere addon maintainers to update the addond.
In how is the video, the user would just need to register a file handler if the addon owner not longer updates the addon.

The user already chose the files they wanted to drag, they don't have to pick some subset again on dropping.

As proposed in the video all is automatically selected.
If the user only drops n images all will be selected, only in the case where user would wants to import a subset with different settings it will require to the user to filter.

The way I would present it is that, you're going to import all the files you dragged in, there's no changing that. If there are multiple file types, it could show a separate expandable panels for each, with a parent panel per file type. But still with a single button to import everything, not a separate import button for each.

It would not work as well if several importers can use the same files.

>As for the design in the video, I think this is getting too complex. I think it's more complex as the patch is now in terms of UX. For example, if an importer only supports one file for call, the user has to drag and drop multiple times, and even worse, if the input parameters are the same, the user has to configure the settings again and again. Also current state forces to update operators, so that they do something different if they are invoked with a path (this to avoid call a `fileselect` window for example) This would requiere addon maintainers to update the addond. In how is the video, the user would just need to register a file handler if the addon owner not longer updates the addon. >The user already chose the files they wanted to drag, they don't have to pick some subset again on dropping. As proposed in the video all is automatically selected. If the user only drops `n` images all will be selected, only in the case where user would wants to import a subset with different settings it will require to the user to filter. >The way I would present it is that, you're going to import all the files you dragged in, there's no changing that. If there are multiple file types, it could show a separate expandable panels for each, with a parent panel per file type. But still with a single button to import everything, not a separate import button for each. It would not work as well if several importers can use the same files.
Jesse Yurkovich commented 2023-12-31 01:45:18 +01:00
Member
Copy Link

My preference would also be to iterate on further ideas separately if possible.

For importers that only support one file per call, it would be good to try to change those regardless of drag-drop support. Script authors who use those operators would also appreciate being able to just provide a list of files to import as well.

As a last resort we could loop over the files ourselves and repeatedly call the operator to give the user the illusion that multiple files are supported (all calls would use the same settings). Would that help unify the experience in a meaningful way for the implementation?

The main benefit of the latest demo seems to be the ability to change settings for just a subset of the dropped files. Unsure if we really need to worry about that part.

Would drag-dropping multiple file types at once, say .obj and .usd, still be possible outside of this new UI prototype? That, to me, might be a more compelling scenario to support.

My preference would also be to iterate on further ideas separately if possible. For importers that only support one file per call, it would be good to try to change those regardless of drag-drop support. Script authors who use those operators would also appreciate being able to just provide a list of files to import as well. As a last resort we could loop over the files ourselves and repeatedly call the operator to give the user the illusion that multiple files are supported (all calls would use the same settings). Would that help unify the experience in a meaningful way for the implementation? The main benefit of the latest demo seems to be the ability to change settings for just a subset of the dropped files. Unsure if we really need to worry about that part. Would drag-dropping multiple file types at once, say .obj and .usd, still be possible outside of this new UI prototype? That, to me, might be a more compelling scenario to support.
Brecht Van Lommel commented 2023-12-31 04:16:32 +01:00
Owner
Copy Link

We could consider making multi file support in operators a requirement for registering them as file handlers. Maybe it's better to make that requirement now rather than dragging along support for single file import operators for a long time.

As proposed in the video all is automatically selected.
If the user only drops n images all will be selected, only in the case where user would wants to import a subset with different settings it will require to the user to filter.

I don't think this aspect should be interactive. To me drag & drop is supposed to be a simple operation. If you want more fine grained control you can drag & drop multiple times.

I would more imagine like an expanded enum at the top, with short names for the file types. There you can switch between the settings for them. And then an import all button at the button.

| USD | FBX | OBJ |

 ... Settings go here ...

                           | Import All |

In a future unified "Import .." operator in the file menu, I think it should work the same way. You can set the settings for each file type in the sidebar, but the file dialog would still have a single "Import" button to import all and dismiss the dialog.

It would not work as well if several importers can use the same files.

There can still be an enum to switch between the importer for a given file extensions. But to be honest, I'd also be fine not supporting that at all and always using one file handler for import. Or leaving it for future work.

What I want to avoid is somehow make it the user's responsibility to go through all the file types and not forget any file types, or import the same files multiple times.

We could consider making multi file support in operators a requirement for registering them as file handlers. Maybe it's better to make that requirement now rather than dragging along support for single file import operators for a long time. > As proposed in the video all is automatically selected. If the user only drops n images all will be selected, only in the case where user would wants to import a subset with different settings it will require to the user to filter. I don't think this aspect should be interactive. To me drag & drop is supposed to be a simple operation. If you want more fine grained control you can drag & drop multiple times. I would more imagine like an expanded enum at the top, with short names for the file types. There you can switch between the settings for them. And then an import all button at the button. ``` | USD | FBX | OBJ | ... Settings go here ... | Import All | ``` In a future unified "Import .." operator in the file menu, I think it should work the same way. You can set the settings for each file type in the sidebar, but the file dialog would still have a single "Import" button to import all and dismiss the dialog. > It would not work as well if several importers can use the same files. There can still be an enum to switch between the importer for a given file extensions. But to be honest, I'd also be fine not supporting that at all and always using one file handler for import. Or leaving it for future work. What I want to avoid is somehow make it the user's responsibility to go through all the file types and not forget any file types, or import the same files multiple times.
Guillermo Venegas commented 2023-12-31 17:51:53 +01:00
Author
Contributor
Copy Link

I don't think this aspect should be interactive. To me drag & drop is supposed to be a simple operation. If you want more fine grained control you can drag & drop multiple times.

For me to be interactive does not harm the user's workflow. If user just wanna import single file the user just drop a single file and perform a simple operation.
But if the user just wanna pick files and let blender tell him can do let him and choose, its nice to have this, and not to have to pick and drop again and again.

I think it is better to compare how the workflow is improved with some videos

--- Current Additional patch
Just one file drop (proposed can be improved to not show the ui_list at all)
Dropping file for the same file handler (here problems begins with current state)
Drop everything and see what can be done with the files
>I don't think this aspect should be interactive. To me drag & drop is supposed to be a simple operation. If you want more fine grained control you can drag & drop multiple times. For me to be interactive does not harm the user's workflow. If user just wanna import single file the user just drop a single file and perform a simple operation. But if the user just wanna pick files and let blender tell him can do let him and choose, its nice to have this, and not to have to pick and drop again and again. I think it is better to compare how the workflow is improved with some videos |---|Current|Additional patch| |---|---|---| |Just one file drop (proposed can be improved to not show the ui_list at all)|<video src="/attachments/3eff83aa-6a1e-44af-997b-bfacdf7345d3" title="2023-12-31 10-28-44.mp4" controls></video>|<video src="/attachments/7e5a362f-137a-4853-b666-7e371c1a6ac2" title="2023-12-31 09-51-30.mp4" controls></video>| |Dropping file for the same file handler (here problems begins with current state)|<video src="/attachments/56f06336-5351-423b-a3fe-f4c63ccff1b2" title="2023-12-31 09-58-40.mp4" controls></video>|<video src="/attachments/7c60fd35-576b-4ebe-88f7-626335b22aea" title="2023-12-31 09-53-05.mp4" controls></video>| |Drop everything and see what can be done with the files|<video src="/attachments/6e3bedb9-1a03-46d0-9eb5-b6f63580f3f8" title="2023-12-31 10-02-32.mp4" controls></video>|<video src="/attachments/6bcd5340-d1d7-4b19-91b3-e25e26ba4532" title="2023-12-31 10-19-40.mp4" controls></video>|
2023-12-31 09-58-40.mp4
3.4 MiB
2023-12-31 10-02-32.mp4
3.7 MiB
2023-12-31 10-28-44.mp4
2.6 MiB
2023-12-31 09-51-30.mp4
2.4 MiB
2023-12-31 10-19-40.mp4
2.4 MiB
2023-12-31 09-53-05.mp4
2.7 MiB
❤️ 2
Brecht Van Lommel commented 2024-01-01 23:32:26 +01:00
Owner
Copy Link

@guishe I agree it's better to support importing multiple file types by dragging once. What I'm saying is that the UI for doing that should be simpler than your current implementation.

@guishe I agree it's better to support importing multiple file types by dragging once. What I'm saying is that the UI for doing that should be simpler than your current implementation.
Jesse Yurkovich commented 2024-01-05 01:48:49 +01:00
Member
Copy Link

@guishe We'd like to get the initial work in this PR committed for 4.1. Iteration on the UI and other convenience aspects can then happen on top of that and would be easier to track and review. Does that sound ok? If so I'll plan on committing this sometime tomorrow once I give it another quick test locally.

@guishe We'd like to get the initial work in this PR committed for 4.1. Iteration on the UI and other convenience aspects can then happen on top of that and would be easier to track and review. Does that sound ok? If so I'll plan on committing this sometime tomorrow once I give it another quick test locally.
Guillermo Venegas commented 2024-01-05 03:14:14 +01:00
Author
Contributor
Copy Link

That's fine with me!
I just got a little too excited about the improvements I propose #116047 (comment), but #116724 it's still in a very early stage.

That's fine with me! I just got a little too excited about the improvements I propose https://projects.blender.org/blender/blender/pulls/116047#issuecomment-1092682, but #116724 it's still in a very early stage.
👍 1
Jesse Yurkovich commented 2024-01-05 08:04:00 +01:00
Member
Copy Link

Actually, can you merge in main on your side. Han's commit conflicts a little bit.

Actually, can you merge in main on your side. Han's commit conflicts a little bit.
Guillermo Venegas added 2 commits 2024-01-05 09:22:51 +01:00
buildbot/vexp-code-patch-lint Build done. Details
buildbot/vexp-code-patch-linux-x86_64 Build done. Details
buildbot/vexp-code-patch-darwin-arm64 Build done. Details
buildbot/vexp-code-patch-windows-amd64 Build done. Details
buildbot/vexp-code-patch-darwin-x86_64 Build done. Details
buildbot/vexp-code-patch-coordinator Build done. Details
9711db63c9 update with main changes
Jesse Yurkovich commented 2024-01-06 00:19:52 +01:00
Member
Copy Link

@blender-bot build

@blender-bot build
Jesse Yurkovich merged commit 1254fee589 into main 2024-01-06 03:51:57 +01:00
Sign in to join this conversation.
Reviewers
No reviewers
Julian Eisel
Jesse Yurkovich
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset Browser

  
Interest
Asset Browser Project Overview

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Collada

  
Interest
Compatibility
This issue affects/is about backward or forward compatibility

  
Interest
Compositing

  
Interest
Core

  
Interest
Cycles

  
Interest
Dependency Graph

  
Interest
Development Management

  
Interest
EEVEE

  
Interest
EEVEE & Viewport

  
Interest
Freestyle

  
Interest
Geometry Nodes

  
Interest
Grease Pencil

  
Interest
ID Management

  
Interest
Images & Movies

  
Interest
Import Export

  
Interest
Line Art

  
Interest
Masking

  
Interest
Metal

  
Interest
Modeling

  
Interest
Modifiers

  
Interest
Motion Tracking

  
Interest
Nodes & Physics

  
Interest
OpenGL

  
Interest
Overlay

  
Interest
Overrides

  
Interest
Performance

  
Interest
Physics

  
Interest
Pipeline, Assets & IO

  
Interest
Platforms, Builds & Tests

  
Interest
Python API

  
Interest
Render & Cycles

  
Interest
Render Pipeline

  
Interest
Sculpt, Paint & Texture

  
Interest
Text Editor

  
Interest
Translations

  
Interest
Triaging

  
Interest
Undo

  
Interest
USD

  
Interest
User Interface

  
Interest
UV Editing

  
Interest
VFX & Video

  
Interest
Video Sequencer

  
Interest
Virtual Reality

  
Interest
Vulkan

  
Interest
Wayland
Issues relating to Wayland windowing support.

  
Interest
Workbench

  
Interest: X11

Issues relating to Xorg/X11 support.

  
Legacy
Blender 2.8 Project

  
Legacy
Milestone 1: Basic, Local Asset Browser

  
Legacy
OpenGL Error

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
Module
Animation & Rigging

  
Module
Core

  
Module
Development Management

  
Module
EEVEE & Viewport

  
Module
Grease Pencil

  
Module
Modeling

  
Module
Nodes & Physics

  
Module
Pipeline, Assets & IO

  
Module
Platforms, Builds & Tests

  
Module
Python API

  
Module
Render & Cycles

  
Module
Sculpt, Paint & Texture

  
Module
Triaging

  
Module
User Interface

  
Module
VFX & Video

  
Platform
FreeBSD

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Priority
High

  
Priority
Low

  
Priority
Normal

  
Priority
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Info from Developers

  
Status
Needs Information from User

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Patch

  
Type
Report

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#116047
No description provided.
Delete Branch "guishe/blender:fh-dnd-support"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?