Adding generic Drag&Drop to Blender for file formats (obj, dae, bvh, ...) #44670

Open
opened 2015-05-11 16:37:55 +02:00 by Gaia Clary · 43 comments
Member

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

  • How to specify import options
  • How to handle Python based drop handlers (especially when the addon gets disabled)
  • How to handle situation where two drop handlers are defined which handle same file type.
  • Unify Python and C (the OpenCollada module is not Python)

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.

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 - How to specify import options - How to handle Python based drop handlers (especially when the addon gets disabled) - How to handle situation where two drop handlers are defined which handle same file type. - Unify Python and C (the OpenCollada module is not Python) I have made a patch [D1292](https://archive.blender.org/developer/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.
Author
Member

Changed status to: 'Open'

Changed status to: 'Open'
Author
Member

Added subscriber: @GaiaClary

Added subscriber: @GaiaClary
Gaia Clary self-assigned this 2015-05-11 16:38:21 +02:00

Added subscriber: @bliblubli

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:

filter_glob = StringProperty(
            default="*.ext",
            options={'HIDDEN'},
            )

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.

Thank you Gaia :) Importers all have a filter already (to only see the relevant file in blender's file browser). It looks like that: ``` filter_glob = StringProperty( default="*.ext", options={'HIDDEN'}, ) ``` 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

Added subscriber: @ideasman42

@bliblubli. good suggestion.

Using filter_glob can work, pass to BLI_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.

@bliblubli. good suggestion. Using `filter_glob` can work, pass to `BLI_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: @mont29
Member

Added subscriber: @Ton

Added subscriber: @Ton
Member

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.

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.
Author
Member

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 :)

I have added my implementation of the ideas above, see [D1292](https://archive.blender.org/developer/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 :)
Member

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.

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?

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?
Author
Member

@bliblubli How can i find out if an operator that has the filter_glob property set is a file Importer?

@bliblubli How can i find out if an operator that has the filter_glob property set is a file Importer?

In bl_info = {
....

  "location": "File > Import",

....

  "category": "Import-Export"}

location should be enough.

In bl_info = { .... ``` "location": "File > Import", ``` .... ``` "category": "Import-Export"} ``` location should be enough.
Author
Member

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)

Kaito 17:45:44:
nice simple code job for aspiring dev: 
make .obj drop work in viewport
anyway if obj works, same can be for fbx etc
the whole import crap - although for import you need menus with settings...
the works like this: you make an operator that can handle a drop event,
which then puts the imported obj on mousepos
Juicyfruit:
handle drop event by looking at extension 
then calling the existing importer ... 
then doing the other stuff you just said
then it is generic all at once
kaito:
the 'drop on mouse pos' code is already there
Juicyfruit:
yes and a lot of importers also
kaito:
you can do it for outliner objects for example
maybe filewindow could do it...
Severin: 17:57:43
shouldn't be too hard I'd say

The patch that i made yesterday does not use :drop on mousepos", however:

  • it implements a drop operator
  • it is generalized to drag&drop any item for which Blender has an Importer

The problems that i have found so far are:

  • Dynamic search over all operators could cause trouble (rejected by Kaito/ton)
  • Can not decide which operator to use when more than one operator provides a file importer for the same extension
  • Expects file import operators to have an idname of "import_*" (The collada importer does not match this rule)
  • Has no way to predefine import options which is a serious problem for some importers.

The advise i got so far (as far as i can understand):

  • do not scan the operators dynamically, but create a fixed list of operators (ton)
  • do not use a fixed list of operators to allow user defined importers (bliblubli)
  • do not add registration to the Addons to avoid unpredictable behavior (blblubli)
  • add a configuration panel to User preferences where drag&drop operators can be enabled/disabled (bliblubli)
  • on the same list provide customization of the default import options (bliblubli)
  • instead of dropping the file into the 3DView just open a file import window with the file preselected.(Juicyfruit?)
  • The drag&drop should allow to import multiple files at once (which might be not so easy to achieve) (campbell)

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 :)

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) ``` Kaito 17:45:44: nice simple code job for aspiring dev: make .obj drop work in viewport anyway if obj works, same can be for fbx etc the whole import crap - although for import you need menus with settings... the works like this: you make an operator that can handle a drop event, which then puts the imported obj on mousepos ``` ``` Juicyfruit: handle drop event by looking at extension then calling the existing importer ... then doing the other stuff you just said then it is generic all at once ``` ``` kaito: the 'drop on mouse pos' code is already there ``` ``` Juicyfruit: yes and a lot of importers also ``` ``` kaito: you can do it for outliner objects for example maybe filewindow could do it... ``` ``` Severin: 17:57:43 shouldn't be too hard I'd say ``` The patch that i made yesterday does not use :drop on mousepos", however: - it implements a drop operator - it is generalized to drag&drop any item for which Blender has an Importer The problems that i have found so far are: - Dynamic search over all operators could cause trouble (rejected by Kaito/ton) - Can not decide which operator to use when more than one operator provides a file importer for the same extension - Expects file import operators to have an idname of "import_*" (The collada importer does not match this rule) - Has no way to predefine import options which is a serious problem for some importers. The advise i got so far (as far as i can understand): - do not scan the operators dynamically, but create a fixed list of operators (ton) - do not use a fixed list of operators to allow user defined importers (bliblubli) - do not add registration to the Addons to avoid unpredictable behavior (blblubli) - add a configuration panel to User preferences where drag&drop operators can be enabled/disabled (bliblubli) - on the same list provide customization of the default import options (bliblubli) - instead of dropping the file into the 3DView just open a file import window with the file preselected.(Juicyfruit?) - The drag&drop should allow to import multiple files at once (which might be not so easy to achieve) (campbell) 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:

  • Let user activate drag and drop with a checkbox (minimal change in UI, no thinking for the user)
  • Use already available (and actually already used) information to make all importers work with new system (minimal programmer work and no breakage)
  • Ask for the import options, either by opening the full import window with file preselected or by just displaying the operator options in a popup (again no thinking for the user and maximal compatibility secured)

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:

  • We agree with Ton. The user should decide (not Blender and not the add-on programmers) which importer to use when he drags and drop a file. Blender already knows which addons are importer (those in the "file -> import" menu) and which format those addons support (with the "filter_glob" part). So to avoid configuration errors from the user and make it easier to choose, just propose relevant addons for every format (instead of browsing the full list). I don't think ton said to use a hardcoded fixed list, because he wants the user to be able to decide.
    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:
    Drag_and_Drop.png
    A way of drawing such a checkbox would be like (this no language just logic):
 if location == "File > Import":
      draw checkbox

.....

 if checkbox.checked:
      drag_and_drop uses bpy.ops.operator_name for filter_glob.default

It's just a quick example, an icon would be better of course.

  • We also agree with Juicifruit the drag and drop should open an import window or at least a popup with just the import options (so just the operator panel which appear at the bottom left in all import addons which have options). Giving the possibility to the user to save those options as default could be nice, but I think it's another Task?
  • Multiple file could be added later, when it already works for 1, it shouldn't be hard to make the operator iterate over a list of paths?
Because of my poor English, a short version of our proposal: - Let user activate drag and drop with a checkbox (minimal change in UI, no thinking for the user) - Use already available (and actually already used) information to make all importers work with new system (minimal programmer work and no breakage) - Ask for the import options, either by opening the full import window with file preselected or by just displaying the operator options in a popup (again no thinking for the user and maximal compatibility secured) ---------------------------------- 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: - We agree with Ton. The user should decide (not Blender and not the add-on programmers) which importer to use when he drags and drop a file. Blender already knows which addons are importer (those in the "file -> import" menu) and which format those addons support (with the "filter_glob" part). So to avoid configuration errors from the user and make it easier to choose, just propose relevant addons for every format (instead of browsing the full list). I don't think ton said to use a hardcoded fixed list, because he wants the user to be able to decide. 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: ![Drag_and_Drop.png](https://archive.blender.org/developer/F174713/Drag_and_Drop.png) A way of drawing such a checkbox would be like (this no language just logic): ``` if location == "File > Import": draw checkbox ``` ..... ``` if checkbox.checked: drag_and_drop uses bpy.ops.operator_name for filter_glob.default ``` It's just a quick example, an icon would be better of course. - We also agree with Juicifruit the drag and drop should open an import window or at least a popup with just the import options (so just the operator panel which appear at the bottom left in all import addons which have options). Giving the possibility to the user to save those options as default could be nice, but I think it's another Task? - Multiple file could be added later, when it already works for 1, it shouldn't be hard to make the operator iterate over a list of paths?
Gaia Clary removed their assignment 2015-05-15 13:50:34 +02:00
Member

Added subscriber: @dna-7

Added subscriber: @dna-7
Member

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.

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

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!

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

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

  • OBJ importer A (addon will be activated)
  • OBJ Importer B (addon already activated)
    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.
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 - OBJ importer A (addon will be activated) - OBJ Importer B (addon already activated) 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:

In #44670#309193, @bliblubli wrote:
A choice like

  • OBJ importer A (addon will be activated)
  • OBJ Importer B (addon already activated)

A big +1 from me for this solution.

RMB DnD might be probematic for most OS's (Windows and OSX open the context menu directly iirc). That said, I *really* like: > In #44670#309193, @bliblubli wrote: > A choice like > - OBJ importer A (addon will be activated) > - OBJ Importer B (addon already activated) A big +1 from me for this solution.

In #44670#309201, @Senshi wrote:
RMB DnD might be probematic for most OS's (Windows and OSX open the context menu directly iirc). That said, I really like:

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)

> In #44670#309201, @Senshi wrote: > RMB DnD might be probematic for most OS's (Windows and OSX open the context menu directly iirc). That said, I *really* like: 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)
Author
Member

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

File -> Import -> "file importer to be used"

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.

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 ``` File -> Import -> "file importer to be used" ``` 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.
Author
Member

Another idea could be to have a drop box in blender maybe within the tool shelf:

Image3.jpg

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...)

Another idea could be to have a drop box in blender maybe within the tool shelf: ![Image3.jpg](https://archive.blender.org/developer/F176930/Image3.jpg) 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...)

In #44670#309553, @bliblubli wrote:
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)

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.

In #44670#309652, @GaiaClary wrote:
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

File -> Import -> "file importer to be used"

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.

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).

In #44670#309664, @GaiaClary wrote:
Another idea could be to have a drop box in blender maybe within the tool shelf:

Image3.jpg

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...)

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).

> In #44670#309553, @bliblubli wrote: > 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) 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. > In #44670#309652, @GaiaClary wrote: > 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 > > File -> Import -> "file importer to be used" > > 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. 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). > In #44670#309664, @GaiaClary wrote: > Another idea could be to have a drop box in blender maybe within the tool shelf: > > ![Image3.jpg](https://archive.blender.org/developer/F176930/Image3.jpg) > > 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...) 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:

  • User drops a file
  • Blender now has a path from which it also knows the file extension.
  • Blender without patch already knows which format are supported by which Operators (import plug-ins declare themselves with their bl_info -> "location" and give the list of supported formats in the "filter_glob" part). It is just knowledge, not a decision making procedure, so not against Ton's philosophy.
  • Blender knowing what possibilities it has, opens a choice menu (like when you call the "convert to" operator) ask the user what to do:
    • import with importer_A (addon already activated)
    • import with importer_B (addon will be activated) (maybe with a different color in the case an activation is first required)
    • import with ...
  • If it was a LMB drag, use default import values. It is consistent with Blender behavior (dropping a .blend opens it without asking for option like "load UI" or "Trusted Source") and with OS behavior.
  • If it was a RMB drag , open the import dialog box for options. (works on Linux and Windows, for OSX, i guess there is a way to remap action or at least offer a combination like LMB+Shift or Alt)

Simple, work for all importers, end-users have full control over what happens, allows both quick import or custom import :)

To summarize: - User drops a file - Blender now has a path from which it also knows the file extension. - Blender without patch already knows which format are supported by which Operators (import plug-ins declare themselves with their bl_info -> "location" and give the list of supported formats in the "filter_glob" part). It is just knowledge, not a decision making procedure, so not against Ton's philosophy. - Blender knowing what possibilities it has, opens a choice menu (like when you call the "convert to" operator) ask the user what to do: - import with importer_A (addon already activated) - import with importer_B (addon will be activated) (maybe with a different color in the case an activation is first required) - import with ... - If it was a LMB drag, use default import values. It is consistent with Blender behavior (dropping a .blend opens it without asking for option like "load UI" or "Trusted Source") and with OS behavior. - If it was a RMB drag , open the import dialog box for options. (works on Linux and Windows, for OSX, i guess there is a way to remap action or at least offer a combination like LMB+Shift or Alt) 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:

  • User drops file with LMB - default import.
  • User hits F6 and is brought to the "regular" modal importer, with the filepath already set (perhaps within some sort of 'REPLACE' context?).
  • User changes settings, hits "Import" (or renamed "OK"), the previously imported model is replaced, and re-imported with the new settings.

This change might be out of scope though, as I could imagine this being implemented for the regular import process as well.

+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: - User drops file with LMB - default import. - User hits F6 and is brought to the "regular" modal importer, with the filepath already set (perhaps within some sort of 'REPLACE' context?). - User changes settings, hits "Import" (or renamed "OK"), the previously imported model is replaced, and re-imported with the new settings. This change might be out of scope though, as I could imagine this being implemented for the regular import process as well.
Author
Member

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.

  • Many file formats need some tweaking of the file import options. Having default options might work sometimes, but not in general. And because of that we need to provide some way to set the import options. And the only way we could think of was to let the drop event open some popup. Which is also not desirable.
  • It may be possible to use the Operator redo panel after dropping an imported file to the 3D View, but this might become a major problem when the imported file is big, then any little tweak in the options will redo the entire file import and that may be annoying.
  • In order to identify which file import operators exist, we have other issues.
    • First, we can not simply read the File->Import menu. There may be importers which are not listed here. Hence we need to determine the import operators in another way.
    • Then we also can not rely on name conventions, because they are broken (for example the Collada importer has been named wrong and does not conform to any name convention, so it would not be added to the list of regular importers.
    • Finally there is still the order of processing, so we have to provide some form of selector from where the correct importer needs to be selected in the case when 2 or more importers serve the same file type.

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.

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. - Many file formats need some tweaking of the file import options. Having default options might work sometimes, but not in general. And because of that we need to provide some way to set the import options. And the only way we could think of was to let the drop event open some popup. Which is also not desirable. - It may be possible to use the Operator redo panel after dropping an imported file to the 3D View, but this might become a major problem when the imported file is big, then any little tweak in the options will redo the entire file import and that may be annoying. - In order to identify which file import operators exist, we have other issues. - First, we can not simply read the File->Import menu. There may be importers which are not listed here. Hence we need to determine the import operators in another way. - Then we also can not rely on name conventions, because they are broken (for example the Collada importer has been named wrong and does not conform to any name convention, so it would not be added to the list of regular importers. - Finally there is still the order of processing, so we have to provide some form of selector from where the correct importer needs to be selected in the case when 2 or more importers serve the same file type. # 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:

In #44670#310792, @GaiaClary wrote:
Many file formats need some tweaking of the file import options. Having default options might work sometimes, but not in general. And because of that we need to provide some way to set the import options. And the only way we could think of was to let the drop event open some popup. Which is also not desirable.

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.

In #44670#310792, @GaiaClary wrote:
It may be possible to use the Operator redo panel after dropping an imported file to the 3D View, but this might become a major problem when the imported file is big, then any little tweak in the options will redo the entire file import and that may be annoying.

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.

In #44670#310792, @GaiaClary wrote:
In order to identify which file import operators exist, we have other issues.

First, we can not simply read the File->Import menu. There may be importers which are not listed here. Hence we need to determine the import operators in another way.

Then we also can not rely on name conventions, because they are broken (for example the Collada importer has been named wrong and does not conform to any name convention, so it would not be added to the list of regular importers.

Finally there is still the order of processing, so we have to provide some form of selector from where the correct importer needs to be selected in the case when 2 or more importers serve the same file type.

  • Is this a real-life scenario? I personally can't think of a situation where this is desirable, but I may be missing something.
  • I'm not familiar with the code, but IIRC, isn't Collada one of the few non-Python importers? I would assume this could be a special case then, or perhaps importers could be registered somewhere. I won't speculate too much on this though, I'm just guessing in the dark here.
  • For me this point is two-fold:
    • I don't think this is a much-occuring situation, so I would forgive a non-perfect workflow here.

As a user, I would really like this selection. It's quick, gives me full control, and doesn't feel obtrusive.

In #44670#310792, @GaiaClary wrote:
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...

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:

  • Can't be achieves in a batch process.
  • Requires a custom scripting solution anyway. (I.e.:
if name.endswith("_rigged"):
    #set setting A
else:
    #set setting B

)

I'm sorry to hear about this decision, but best of luck with filepath DnD regardless!

Cheers,
Parick

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: > In #44670#310792, @GaiaClary wrote: > Many file formats need some tweaking of the file import options. Having default options might work sometimes, but not in general. And because of that we need to provide some way to set the import options. And the only way we could think of was to let the drop event open some popup. Which is also not desirable. 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. > In #44670#310792, @GaiaClary wrote: > It may be possible to use the Operator redo panel after dropping an imported file to the 3D View, but this might become a major problem when the imported file is big, then any little tweak in the options will redo the entire file import and that may be annoying. 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. > In #44670#310792, @GaiaClary wrote: > In order to identify which file import operators exist, we have other issues. > ## First, we can not simply read the File->Import menu. There may be importers which are not listed here. Hence we need to determine the import operators in another way. > ## Then we also can not rely on name conventions, because they are broken (for example the Collada importer has been named wrong and does not conform to any name convention, so it would not be added to the list of regular importers. > ## Finally there is still the order of processing, so we have to provide some form of selector from where the correct importer needs to be selected in the case when 2 or more importers serve the same file type. - Is this a real-life scenario? I personally can't think of a situation where this is desirable, but I may be missing something. - I'm not familiar with the code, but IIRC, isn't Collada one of the few non-Python importers? I would assume this could be a special case then, or perhaps importers could be registered somewhere. I won't speculate too much on this though, I'm just guessing in the dark here. - For me this point is two-fold: - I don't think this is a much-occuring situation, so I would forgive a non-perfect workflow here. ## As a user, I would really like this selection. It's quick, gives me full control, and doesn't feel obtrusive. > In #44670#310792, @GaiaClary wrote: > 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... 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: - Can't be achieves in a batch process. - Requires a custom scripting solution anyway. (I.e.: ``` if name.endswith("_rigged"): #set setting A else: #set setting B ``` ) 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:

  1. Blender actual drag and drop doesn't offer the possibility to set options (.blend files). It will close your current scene, open the new one with defaults (which can be even dangerous because it executes python scripts if autorun is enabled). And we proposed to have a normal DnD (like the actual one, without options) and one with alt pressed to set options. What's wrong with this?
  2. Completely agree but it doesn't remove the possibility of a good scene DnD.
  3. a. Show me an example of a (used by actual users) importer plugin that isn't available in file -> import. If we follow all the "if someone crazy does it" cases, we won't do anything anymore.
    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?
  4. Would be nice yes but it's also a plus that can be added later.
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: 1. Blender actual drag and drop doesn't offer the possibility to set options (.blend files). It will close your current scene, open the new one with defaults (which can be even dangerous because it executes python scripts if autorun is enabled). And we proposed to have a normal DnD (like the actual one, without options) and one with alt pressed to set options. What's wrong with this? 2. Completely agree but it doesn't remove the possibility of a good scene DnD. 3. a. Show me an example of a (used by actual users) importer plugin that isn't available in file -> import. If we follow all the "if someone crazy does it" cases, we won't do anything anymore. 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? 4. Would be nice yes but it's also a plus that can be added later.
Author
Member

@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 :)

@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: @Carolinefangel

Added subscriber: @oweissbarth

Added subscriber: @oweissbarth

Added subscriber: @cschumann

Added subscriber: @cschumann
Member

Added subscriber: @JulianEisel

Added subscriber: @JulianEisel
Member

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.

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](https://archive.blender.org/developer/D4071). They also matter for the Asset Manager.

Added subscriber: @AquaticNightmare

Added subscriber: @AquaticNightmare

Added subscriber: @apprenti90

Added subscriber: @apprenti90

Added subscriber: @chadking

Added subscriber: @chadking

Added subscriber: @IihT2cWA9xiP30BsYphz3EiEISNoScoe

Added subscriber: @IihT2cWA9xiP30BsYphz3EiEISNoScoe

Added subscriber: @AlexeyAdamitsky

Added subscriber: @AlexeyAdamitsky
Philipp Oeser removed the
Interest
User Interface
label 2023-02-10 09:26:30 +01:00
Sign in to join this conversation.
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
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#44670
No description provided.