Drag and drop non-blend files #90531

New Issue

Adrian Stephens · 2021-08-09T03:39:03+02:00

Adrian Stephens commented

2021-08-09 03:39:03 +02:00

Beyond the initial feedback on D12098, I haven't heard anything for a while; so hoping this might be the expected avenue for further discussion?

I propose to extend python operators to enable them to register themselves for drag-and-drop of files from the host OS.

Following the general Operator pattern, the registering is done through a new bl_options flag, 'DRAGDROP', and the Operator's poll and invoke functions are called as usual, but in the context of a drag-and-drop operation.

The operator's poll is called to determine if the dropped file is supported by this operator, usually by examining the filename of the dragged file, which is stored in context.window_manager.dropfile.
If poll returns true, the operator's invoke function is called, with property 'filepath' set to the dropped filename.

There is an existing Operator in wm.py called WM_OT_drop_blend_file which works in this way, but which has had its poll and dropbox registering hardcoded into a C file (blender/editors/screen/screen_ops.c). This proposal would remove the need to do that, and open up the ability to drag and drop other file types into blender.

Addressing some concerns I know about:

Could be done with planned general WM drop box support / Doesn't allow for dropping files into different views

The Operator poll/invoke mechanism seems like a good way to express dragging and dropping in any case, and registering the dropboxes for different views could be done through the Operator's bl_regiontype.

Could be done via a planned file-type registration system

I'm not sure how much file-type registration already exists in blender, but my unsolicited opinion:
At its simplest a filetype might be a mapping of a filename extension to read/write routines, but probably also includes what sorts of things it might contain (images, sounds, 3d meshes), some sort of import/export UI, etc., etc.
But why register such a thing when you can just register an Operator that can be asked if it can read a file, and can automatically load the data into the right structures in memory? A similar argument exists for saving/exporting.
My point is that a filetype is an ephemeral thing that exists only at the boundary of a filename and loaded data, and it's sort-of a good thing that blender doesn't have some sort of list of them.

Multiple file support

When you drag multiple files they can be of different types. Making a per-file determination of what Operator will be called leaves the Operators to only have to consider a single file.
I had thought that this was already supported in blender, but in fact multiple-file dragging had been explicitly disabled. I remove that restriction with D12159

Specifying import UI / choosing to merge in or load file contents

As in WM_OT_drop_blend_file, all those things can be easily done in the Operator's invoke function. This is in contrast with a filetype registration system, where these variations in behaviour would have to be somehow accounted for.
in the case of dragging multiple files I think it would be reasonable to put up a menu or import panel on the first file and then have an option in the UI to use the same options for all subsequent files in this drag; but that would be totally authorable.

I know it looks like I'm mostly just arguing for my patch as-is, and being overly pushy; but I thought it would be best to give you all these thoughts up-front, especially since we're in very different time zones.

Beyond the initial feedback on [D12098](https://archive.blender.org/developer/D12098), I haven't heard anything for a while; so hoping this might be the expected avenue for further discussion? I propose to extend python operators to enable them to register themselves for drag-and-drop of files from the host OS. Following the general Operator pattern, the registering is done through a new bl_options flag, 'DRAGDROP', and the Operator's poll and invoke functions are called as usual, but in the context of a drag-and-drop operation. The operator's poll is called to determine if the dropped file is supported by this operator, usually by examining the filename of the dragged file, which is stored in context.window_manager.dropfile. If poll returns true, the operator's invoke function is called, with property 'filepath' set to the dropped filename. There is an existing Operator in wm.py called WM_OT_drop_blend_file which works in this way, but which has had its poll and dropbox registering hardcoded into a C file (blender/editors/screen/screen_ops.c). This proposal would remove the need to do that, and open up the ability to drag and drop other file types into blender. ------------------------------------ Addressing some concerns I know about: 1. Could be done with planned general WM drop box support / Doesn't allow for dropping files into different views The Operator poll/invoke mechanism seems like a good way to express dragging and dropping in any case, and registering the dropboxes for different views could be done through the Operator's bl_regiontype. 2. Could be done via a planned file-type registration system I'm not sure how much file-type registration already exists in blender, but my unsolicited opinion: At its simplest a filetype might be a mapping of a filename extension to read/write routines, but probably also includes what sorts of things it might contain (images, sounds, 3d meshes), some sort of import/export UI, etc., etc. But why register such a thing when you can just register an Operator that can be asked if it can read a file, and can automatically load the data into the right structures in memory? A similar argument exists for saving/exporting. My point is that a filetype is an ephemeral thing that exists only at the boundary of a filename and loaded data, and it's sort-of a good thing that blender doesn't have some sort of list of them. 3. Multiple file support When you drag multiple files they can be of different types. Making a per-file determination of what Operator will be called leaves the Operators to only have to consider a single file. I had thought that this was already supported in blender, but in fact multiple-file dragging had been explicitly disabled. I remove that restriction with [D12159](https://archive.blender.org/developer/D12159) 4. Specifying import UI / choosing to merge in or load file contents As in WM_OT_drop_blend_file, all those things can be easily done in the Operator's invoke function. This is in contrast with a filetype registration system, where these variations in behaviour would have to be somehow accounted for. in the case of dragging multiple files I think it would be reasonable to put up a menu or import panel on the first file and then have an option in the UI to use the same options for all subsequent files in this drag; but that would be totally authorable. ------------------------------------ I know it looks like I'm mostly just arguing for my patch as-is, and being overly pushy; but I thought it would be best to give you all these thoughts up-front, especially since we're in very different time zones.

Adrian Stephens commented

2021-08-09 03:39:03 +02:00

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

Adrian Stephens commented

2021-08-09 03:39:03 +02:00

Added subscriber: @adrianstephens

Pratik Borhade commented

2021-08-09 03:51:24 +02:00

No description provided.

Adrian Stephens self-assigned this 2021-08-09 06:57:42 +02:00

Thanh Phan commented

2021-08-19 09:37:02 +02:00

Added subscriber: @thanhph111

Campbell Barton commented

2021-08-23 09:42:28 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2021-08-23 09:42:28 +02:00

Exposing drag and drop on an operator level seems like it would only work in limited cases,
as a rule of thumb, I've found it's best to expose internal functionality in a way that maps the internal logic to Python 1:1.

This likely means adding the ability for Python to register drop-boxes just as our C code does.

The reason for this is if we need to support dragging blender data types between areas (for example), we will need this anyway, as a solution that bypasses these details will then be insufficient for implementing things that are possible internally in C.

What I'm unsure of is how this would work with window-level drag and drop, for example - if none of the drop-boxes accept a file, this could fall-back to more general file loading logic.

What I miss is a big-picture design of how drag and drop should work:

List possible uses of drag & drop (external files could represent materials, textures or animations that apply to existing content). Then there are cases where a file might replace the existing loaded file (as with Blend files).
Possible uses of drag and drop within blender windows (support Python drop-boxes handling ID data for example).
Investigating supporting multiple files, check on implementing this (perhaps a test case such as dragging multiple images into the image viewer or sequencer might be good test-cases for supporting loading many files at once).
Make a design that handles these cases which includes proposed API's.

Once this is done the design can be reviewed & approved, it's possible a subset of the functionality could be implemented which doesn't cause conflicts with implementing more involved area level drag and drop in the future.

Exposing drag and drop on an operator level seems like it would only work in limited cases, as a rule of thumb, I've found it's best to expose internal functionality in a way that maps the internal logic to Python 1:1. This likely means adding the ability for Python to register drop-boxes just as our C code does. The reason for this is if we need to support dragging blender data types between areas (for example), we will need this anyway, as a solution that bypasses these details will then be insufficient for implementing things that are possible internally in C. What I'm unsure of is how this would work with window-level drag and drop, for example - if none of the drop-boxes accept a file, this could fall-back to more general file loading logic. --- What I miss is a big-picture design of how drag and drop should work: - List possible uses of drag & drop (external files could represent materials, textures or animations that apply to existing content). Then there are cases where a file might replace the existing loaded file (as with Blend files). - Possible uses of drag and drop within blender windows (support Python drop-boxes handling ID data for example). - Investigating supporting multiple files, check on implementing this (perhaps a test case such as dragging multiple images into the image viewer or sequencer might be good test-cases for supporting loading many files at once). - Make a design that handles these cases which includes proposed API's. Once this is done the design can be reviewed & approved, it's possible a subset of the functionality could be implemented which doesn't cause conflicts with implementing more involved area level drag and drop in the future.

Adrian Stephens commented

2021-09-06 03:45:23 +02:00

In #90531#1210002, @ideasman42 wrote:
Exposing drag and drop on an operator level seems like it would only work in limited cases

I think that's true for drag-and-drop in general, but dragging and dropping files from the host OS is a very limited case, with very specific limited functionality imposed by the OS.
That's why I don't think this should be considered alongside more general intra-app drag and drop. That both go via blender's drop-box mechanism is an implementation detail.
I suppose the question is, are there currently operators that handle both OS-level drag and drop and intra-app drag and drop, and is there any functional benefits to unifying the concepts?

What I miss is a big-picture design of how drag and drop should work:

What I've done with my patch is taken an existing design (used by blend-file drag and drop) and made the minimal tweaks necessary to make it something that doesn't need to be hard-coded like WM_OT_drop_blend_file was. I think that's already a good thing; the ability to then have drag-and-drop for other file types comes 'for free'.

For what this is, I'm having a hard time understanding the need for more design, and I'm not sure I could contribute much to such a discussion. Maybe someone else has opinions on your questions?

For me (and the blender users I know) this is much needed feature that is a big source of frustration, but I understand other people's use cases and priorities are different.

> In #90531#1210002, @ideasman42 wrote: > Exposing drag and drop on an operator level seems like it would only work in limited cases I think that's true for drag-and-drop in general, but dragging and dropping files from the host OS *is* a very limited case, with very specific limited functionality imposed by the OS. That's why I don't think this should be considered alongside more general intra-app drag and drop. That both go via blender's drop-box mechanism is an implementation detail. I suppose the question is, are there currently operators that handle both OS-level drag and drop and intra-app drag and drop, and is there any functional benefits to unifying the concepts? > What I miss is a big-picture design of how drag and drop should work: What I've done with my patch is taken an existing design (used by blend-file drag and drop) and made the minimal tweaks necessary to make it something that doesn't need to be hard-coded like WM_OT_drop_blend_file was. I think that's already a good thing; the ability to then have drag-and-drop for other file types comes 'for free'. For what this is, I'm having a hard time understanding the need for more design, and I'm not sure I could contribute much to such a discussion. Maybe someone else has opinions on your questions? For me (and the blender users I know) this is much needed feature that is a big source of frustration, but I understand other people's use cases and priorities are different.

RUben commented

2021-12-14 23:02:37 +01:00

Added subscriber: @RUben

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Drag and drop non-blend files #90531