Adding generic Drag&Drop to Blender for file formats (obj, dae, bvh, ...) #44670
Labels
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
No Milestone
No project
No Assignees
17 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#44670
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
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?
The idea is to add a generic Drag and Drop to Blender.
Drop handlers could be dynamically registered (e.g. from Python)
Problems to be discussed
I have made a patch D1292 for OpenCollada to see how it could be done from within C.
This patch allows to drag&drop directly from the native file browser into the Blender 3DView.
It was rather easy to do, but it cries for "generic solution".
Ideas how this could be done in more detail are very welcome.
Changed status to: 'Open'
Added subscriber: @GaiaClary
Added subscriber: @bliblubli
Thank you Gaia :) Importers all have a filter already (to only see the relevant file in blender's file browser). It looks like that:
You can use those declared supported extension from all plugins beginning with "io_" (make a table at blender start?)
It would allow to know which format can be imported without the need of activating the addons. If the addon is activated, just ask for parameters, if not ask first if it should be enabled?
It would also avoid conflict of addons overwriting each other capabilities if many support the same format. For cases where 2+ importers are available, show possibilities and let user decide?
It would also make all existing addons compatible with drag and drop out of the box, also those which are not updated anymore.
Just the result of a brainstorming about different designs with colleagues. We hope it helps.
Added subscriber: @ideasman42
@bliblubli. good suggestion.
Using
filter_glob
can work, pass toBLI_testextensie_glob
.Eventually we may want to use a callback for operators to test the exact filepath. But to begin with using
filter_glob
is OK.Minor note, don't think having a table of
io
operators is really needed... we can always do it if scanning operators is a performance bottleneck. Since operators be loaded dynamically - maintaining the list of IO operators seems more trouble then its worth.Added subscriber: @mont29
Added subscriber: @Ton
Automatic registry of operators to run is a really bad idea. In any case, not only this one. You can easily picture how this runs out of control.
Just make a list of operators per handler you want to call. Software shouldn't start thinking for users, especially not when usability comes in the picture.
I have added my implementation of the ideas above, see D1292
However there are some issues with this. Most apparent: finding the import operators is not as straight forward as it appeared on first look. I implemented this by adding an additional check on the Operator idname. But as you can see in the Differential, i already stumbled over the operator name of the Collada importer which does NOT comply to the conventions (importer operator names begin with "IMPORT...")
Then currently the import operator is called with default settings. This may work sometimes, but not in general. The Collada Importer can handle this nicely because it uses an operator Panel. Other importers do not provide the operator panel, so thats bad.
Then what shall we do when 2 or even more importers exist for the same file type? Currently ther eis no way to tell which importer is actually called.
@Ton Having a list of operators would work nicely for Blender internal Importers. But then users can not add drag&drop for their own importers. This might be a "small" solution though, i would not complain if others agree with that!
In order to get this into a better shape i would need some serious advises to make this better.
one idea could be to add a property to all addons which want to support the drag&drop feature. Maybe these addons might then also need to provide an operator panel. And all other importers would then be ignored. This could help a lot to identify which operators are actually allowed to handle drag&drop.
Please be so kind and tell me how to proceed.
Thanks for any constructive help :)
Drag and drop functionality is just like menus or buttons or shortcuts. Each item and each option should be possible to enable or disable or configure. That's a bit of work, but it's useful to learn and keep in end user control.
We should also be looking at workflow configs, or for 'Blender 101' too. Auto-UI options then don't help much.
If you then allow addons to take over existing (by other people designed) UIs you just create new problems. Buttons popping up everywhere, menus changing on the fly, ... just lets keep things small and simple.
Ton idea is good, just use the "filter_glob" data to know which program can open which format and make a list for each format to make it easier for users to choose the appropriate addon. But then in the user preferences, let the user choose in that list which importer to use (actually like Linux or Windows or MacOS do). If you want importer to declare themselves as the one importer to use, you will just make random behavior (depending on the order they will register). And it would make old importers incompatible.
For the options, just open the importer window with the dragged file already selected to let the user choose the import options?
Does it take really long to parse all add-ons? I mean, they are already parsed anyway to appear in the add-ons list, so maybe it's not required to look for a pattern in the name, just look everywhere?
@bliblubli How can i find out if an operator that has the filter_glob property set is a file Importer?
In bl_info = {
....
....
location should be enough.
To understand better what should be done i have asked for advise from more knowledgeable coders.
Meanwhile i have also looked up in the irc chat logs from last Sunday. Here is what i found (edited a bit)
The patch that i made yesterday does not use :drop on mousepos", however:
The problems that i have found so far are:
The advise i got so far (as far as i can understand):
If i shall go ahead with this then please let me know what the next steps you want to see implemented.
Or alternatively take over this task and do it yourself :)
Because of my poor English, a short version of our proposal:
Longversion of proposal
So it seems many of us don't have English as mother-tong, I'll try to explain better what I wrote:
In fact, for this part, to make minimal changes to UI, we could just add a second checkbox in the "User Preferences -> addon" panel just for import addons:
A way of drawing such a checkbox would be like (this no language just logic):
.....
It's just a quick example, an icon would be better of course.
Added subscriber: @dna-7
From the e-mail title "Generic Drag&drop for Blender" I got all excited that someone was actually going to finish my work on implementing generic python DnD operators that could co-exist with (or completely replace) the C-based ones -- the funny part is while I was working on it I was thinking "this is nice and all but who would really write a custom DnD operator?" but now I see there are some very good use cases.
With real generic DnD py-operators each importer could (de)register their own DnD operator using the same mechanism that is used now for general im/exporter bookkeeping which would solve all the problems discussed this far aside from the 'multiple importers per file type' since the first DnD operator that polls successfully 'wins'.
IIRC there wasn't a whole lot left to do but I never got around to finishing it due to Real Life™ taking up all my blender hacking time, if no one takes this up I could probably look into it again in a couple weeks when I get some free time...or if someone does I have a fair bit of knowledge on what it would take to finish it.
Added subscriber: @Senshi
After giving this some thought, here's my initial $0.02 on the usability side of things:
Users would choose drag 'n drop over its corresponding menu entry because of speed. This is an assumption, but one I believe makes sense to make for at least a good portion of IO use-cases, and also one I believe is very important to keep in mind.
Because of that, I would expect a DnD action of any file-type to just import the model using the importer's default settings (1). Just make something appear as soon as possible.
Some people suggested using the operator panel to then set the import settings, but I think it's generally undesirable to have the importer run after every property change. Instead, I think pressing F6 (or clicking a "Set import settings" button from the operator panel) should open the default import window, but with the file path already set. Clicking "Import" then replaces the DnD-imported model. Imho this would keep things as consistent and flexible as possible.
To quickly get back to (1), I can imagine some scenarios where people are working with huge files and accidentally dropping a 300MB file would be annoying at best, so I think there may be a case to be made for an "Open importer panel on file drop" user pref., though I think DnD actions should probably just be kept as simple and compact as possible.
As for a second checkbox on IO addons, I feel like it would only move the problem. For example, what if I accidentally check the box on two FBX importers? I guess you could do another search and disable all other FBX importers, but that is starting to feel like hocus pocus to me. (What if I have both an ABC importer, as well as an ABC, DEF, GHI multi-importer? Or what if I just accidentally click and immediately disable it again? Now I have to go and find the original one to re-enable.)
Instead, when multiple suitable importers are found I would prefer to see a selection menu similar to "Open recent". This puts control in the hands of the user at runtime, and they can even switch based on, say, pre-201x models and newer ones of the same type.
Lastly, on the topic of disabled add-ons, I agree add-ons should never enable on their own. That said though, I do believe it would be very convenient if we could enable it on the spot, right after dragging. I don't have a clear solution here, but here is my thought process: If we had modal popups, I would expect one like:
You are attempting to import a .ABC file, but the ABC importer is currently disabled. Would you like to enable it?
Though this also runs into the problem of "what if there are two ABC importers?". Perhaps we could instead open the user preferences, and automatically unfold the first suitable importer we can find. Though this is already a bit too much of deciding for the user imho. I guess initially just showing a warning would help, and this is probably already getting out of scope, but I thought it was fun to think about regardless.
Anyway, I hope this makes it in at some point! It sounds like a great UI improvement. Good luck!
Added subscriber: @Lapineige
If Ton agree that the user making a drag and drop action is already a user voluntary choice (so not Blender thinking for the user), then I completely agree on the proposal of letting user decide at runtime which importer to use if more than one importer is possible and also choosing then to enable the addon or not. A choice like
Best variant would be to have a LMB and RMB drag and drop like in modern file browsers. The left one would make an automatic import with default parameters, the right one would popup a panel to let the user define the import parameters.
RMB DnD might be probematic for most OS's (Windows and OSX open the context menu directly iirc). That said, I really like:
A big +1 from me for this solution.
just tested RMB DnD on Windows 7 (with a .blend file dragged to Blender's window) and it doesn't call the OS right-clik menu (in this case it just opened the file in blender)
one "minimal" approach could also be to make the File Import Window drag&drop aware. Then the user would have to "prepare" Blender by first calling
Then instead of using the navigation system in the importer just drag&drop from the system file browser.
Sure, this is not a replacement for the generic "drag&drop anywhere" but maybe its a partial solution that at least works in a meaningful and doubtless way.
Another idea could be to have a drop box in blender maybe within the tool shelf:
Depending on what file gets dropped the appropriate file importer's operator import panel is displayed.
So this is like a "quick import from toolshelf". however this is not really better than my previous idea, except
that the drop box now identifies the importer "automatically" (which still is not clear howto do...)
Oh, ok, my bad then! I only have OSX at the moment, and can confirm RMB does not allow dragging from Finder in 10.9.4.
I am not opposed to this in any way, though this sounds more like a "generic drag and drop for filepaths" than the original proposal.
However, it still doesn't speed up the workflow in a way I was hoping for. A quick example: Yesterday I downloaded a model pack that had ±30 individual, poorly-named XNALara files. Having to go through "File > Import > Importer" every single time is just a huge hassle. Now the XNALara importer has the "advantage" of not having many import settings, so it's easy to envision a DnD for that. However, I still feel like the concept and workflow stands for other, more complex formats as well(especially if we could quickly switch to the standard import view, i.e. with F6).
I agree this at least eliminates the need for menu traversing, but compared to a scene DnD I still prefer the other. An obvious advantage is that we now have the settings right there with us, but the con is that you still have to open the Toolshelf en go to the Import tab, as well as losing the "drop under mouse" functionality (not too big a deal, but still very usefull).
To summarize:
Simple, work for all importers, end-users have full control over what happens, allows both quick import or custom import :)
+1 on that, for sure. This seems to me like the most useful and complete setup. Holding alt on drop for OSX (or even Windows and Linux) sounds like a great solution as well. No control is lost, and it can be a huge speedup.
The only thing I would add (and am still vouching for) is to add a quick switch to the modal importer, so one can change settings. In this case:
This change might be out of scope though, as I could imagine this being implemented for the regular import process as well.
Hi;
We have been discussing this topic in #blendercoders on irc. Unfortunately we identified some issues which make it a little complicated to get a satisfying generic drag&drop for file imports.
we have also discussed if it might be beneficial to provide some sort of batch import tool, which would allow to collect files and import them "all at once" but then we again have to find a good way to specify the import options per file...
At the end it turned out that the more we where thinking about it the less it appeared to be an easy thing to do. So the decision was made to implement a minimalistic drag&drop which would avoid all of the issues that we have identified:
This drag&drop works only on the file import window, hence the to be used operator has already been specified (by the user) and the operator panel is available for tweaking the import options before the import is performed.
The current minimalistic implementation actually does simply preset the filename and path fields of the file import window, thus the user no longer needs to navigate in blender's file browser.
Yes, it is just a small benefit, but maybe its better than nothing at all.
I understand a decision has been made, and I agree this is better than nothing, but I still believe a scene DnD operator would be very beneficial. So just for future reference I would like to address some of these points one final time:
The first point to note here is that a DnD importer wouldn't replace the existing one. If you know you're going to import a 300MB FBX and need to set custom options, you would likely go through the File > Import menu.
@bliblubli also suggested that a bare DnD imports an object with default settings, while holding alt would open the standard importer window with the filepath already set. I personally think this is a great idea and puts even more control in the hands of the user.
Lastly, there are also a good number of formats where the default settings work just fine. STL, OBJ and XNALara spring to mind. Even for some FBXs and DAEs the default settings might suffice.
I have addressed this exact point earlier as well, but I believe the Operator Panel in this case should be an exception, and give way to the standard import window. I.e.: Go there on the press of F6, and/ or place a "Change Import Settings" button in the Operator Panel that brings you there.
If this is not possible a "re-import" button might be feasible, similar to how some CPU-intensive generators do (did?). That way you can change all the properties you need before re-importing.
As a user, I would really like this selection. It's quick, gives me full control, and doesn't feel obtrusive.
I think this is out-of-scope for now, but I wouldn't worry about per-file settings. The whole idea of a batch import is to quickly process a bunch of objects. I think it's safe to assume that nine out of ten times the same exact settings will suffice. If not, the user likely needs a level of control that either:
)
I'm sorry to hear about this decision, but best of luck with filepath DnD regardless!
Cheers,
Parick
Huh? I know it's not a promised enhancement so you can shut it down, but it's a great idea and would really enhance workflow, so I find it a shame to kill it so easily and so early. You say all time we shouldn't criticize but instead make good proposal and I completely agree. I'm also ok if nobody reads what's written here, but then at least tell us we are not taken into account so we spare some time. Nothing for you specifically Gaia, but as we don't know who said what on IRC:
b. doesn't exist if we take 3.a. and anyway, why prevent better user experience just because some mistakes where made by the devs (no offense here, it happens and it's ok but shouldn't be an excuse, add exceptions if you like this path)
c. It's also clear, but it's not a stopper?
@bliblubli I do not want to step ahead and make new proposals now. I rather want to first wait until this minimalistic implementation is ready for getting committed. Then we can talk about the next step towards the ultimate DnD user experience :)
Added subscriber: @Carolinefangel
Added subscriber: @oweissbarth
Added subscriber: @cschumann
Added subscriber: @JulianEisel
Dragging IO files from the system browser into Blender is definitely something that users expect to work.
I don't think the approach discussed here is the way to go. As noted above, it has a number of issues.
Instead, Add-ons should be able to register their own drop-targets (e.g. 3D View) with a poll function to check if they apply (e.g. checking the file extension). If the poll succeeds during the drop event, the import operator can be called. It may optionally show settings then. Similar to how we show a menu when dragging in a .blend file to decide between link, append or open.
This is roughly how drag & drop already works internally. This would also be the "natural" design for the current design of event handlers in Blender.
I don't think we have to deal with the case of multiple importers for the same file type. The first one executed successfully by the event system "wins". It's not a common issue in practice I believe, and doesn't warrant the complexity. There would probably be further issues otherwise, like duplicated menu entries or equal operator
bl_idname
's if both follow the naming convention.There are many ways to mess up your Blender configuration, especially with Add-ons and custom keymaps.
Now, the issue is that the BPY doesn't currently allow registering custom drop-targets (currently called "drop-boxes"). There's also no support for dragging in multiple files at once yet.
Both these things are on the radar to be addressed however, see D4071. They also matter for the Asset Manager.
Added subscriber: @AquaticNightmare
Added subscriber: @apprenti90
Added subscriber: @chadking
Added subscriber: @IihT2cWA9xiP30BsYphz3EiEISNoScoe
Added subscriber: @AlexeyAdamitsky