Rationalize the existing drag/drop handling code with the new FileHandlerType support #117621

New Issue

Jesse Yurkovich · 2024-01-29T05:50:08+01:00

Jesse Yurkovich commented

2024-01-29 05:50:08 +01:00

Problem

Blender has two pieces of machinery that handles drag/drop support for files. The original code which directly calls WM_dropbox_add for each interested Editor and the new FileHandlerType code which allows dynamic, runtime, registration of drag/drop handlers.

These two are in conflict with one another as the original set of dropboxes will typically "steal" processing away from later handlers. E.g. It's not possible to write a FileHandler that handles .py file types for the text editor. Nor would it be possible to write a FileHandler that handles Image types for the 3DViewport etc.

Possible solution

FileHandlers already have a conflict resolution mechanism if more than one handler can process a given file type. We should explore what it would take to implement the original dropboxes in terms of FileHandlers.

Pending tasks

Image drops in the 3d viewport (commit 8b6a21c122, PR blender/blender!117728)
Image drops in the Image editor (commit b97ac126f8, PR blender/blender!117707)
Image drops in the Node editor which should support multiple at a time

TODO's

If there are multiple FileHandlers enabled for Image drop in the viewport, the dropped image location may not be as expected after the user interacts with the conflict resolution popup dialog since the mouse location would most likely change. PR feedback was to look into saving the initial event coordinates in this case.

### Problem Blender has two pieces of machinery that handles drag/drop support for files. The original code which directly calls `WM_dropbox_add` for each interested Editor and the new `FileHandlerType` code which allows dynamic, runtime, registration of drag/drop handlers. These two are in conflict with one another as the original set of dropboxes will typically "steal" processing away from later handlers. E.g. It's not possible to write a FileHandler that handles `.py` file types for the text editor. Nor would it be possible to write a FileHandler that handles Image types for the 3DViewport etc. ### Possible solution FileHandlers already have a conflict resolution mechanism if more than one handler can process a given file type. We should explore what it would take to implement the original dropboxes in terms of FileHandlers. ### Pending tasks * [x] Image drops in the 3d viewport (commit 8b6a21c122eebf043732630cd55e77edf6236efa, PR blender/blender!117728) * [x] Image drops in the Image editor (commit b97ac126f8489fbd4730a95d14a70ad446ca5f4d, PR blender/blender!117707) * [ ] Image drops in the Node editor which should support multiple at a time ### TODO's * [ ] If there are multiple FileHandlers enabled for Image drop in the viewport, the dropped image location may not be as expected after the user interacts with the conflict resolution popup dialog since the mouse location would most likely change. PR feedback was to look into saving the initial event coordinates in this case.

Jesse Yurkovich added the

labels 2024-01-29 05:50:08 +01:00

Guillermo Venegas commented

2024-02-01 17:08:51 +01:00

There are some that are easy to port (#117728)
Others require a little more work to improve usability (#117707)

There are some that are easy to port (https://projects.blender.org/blender/blender/pulls/117728) Others require a little more work to improve usability (https://projects.blender.org/blender/blender/pulls/117707)

Jesse Yurkovich referenced this issue

2024-03-14 21:43:59 +01:00

Complete File Handler support #119488

Guillermo Venegas referenced this issue

2024-03-16 10:43:51 +01:00

bpy.types.FileHandler doesn't work propely with image an video files, bpy.ops.object.drop_named_image take over #119552

Guillermo Venegas referenced this issue

2024-04-02 20:55:41 +02:00

UI: Improve image sequence detection at opening files #120185

Sign in to join this conversation.