Assign value to property by dropping to scene tree

[KoBeWi]

I had this idea for a long time and gave it a shot today. Somewhat related to #16464 and #10684.
Basically, you can drop files onto scene tree nodes and they will be assigned to properties.

If you hold Ctrl, a popup will appear with list of available properties. If not, the resource is assigned to the first compatible property.
(see my last comment)

[jcostello]

Does it works to materials in a mesh for example?

[Calinou]

Does it works to materials in a mesh for example?

It should work in theory, the issue is there are 3 locations in which the material can be defined (from top to bottom in the inspector):

1. In the MeshInstance's Mesh resource itself.
2. In the MeshInstance's Materials property (Surface Material Override in master). If the mesh has multiple materials, the first surface will likely "win".
3. In the MeshInstance's GeometryInstance Material Override property.

I think the one that will "win" here is the second one, and this is usually what you want anyway (as changes to the material will be kept after reimporting the mesh).

[KoBeWi]

Yes, surface material override is supported, same with the other material override property. You can't only put the resource into mesh, because its material is inside a sub-resource. Dropping on nodes only works with properties of the node, not its sub-resources.

[groud]

This feature is a really good idea!

If you hold Ctrl, a popup will appear with list of available properties. If not, the resource is assigned to the first compatible property.

I think this should be made simpler. Instead, I would simply count the number of compatible properties, if there's only one, assign it directly, and if there are more than one, display the list. It's simpler and avoid using a key modifier which might sometimes be hard to discover.

[KoBeWi]

I think this should be made simpler. Instead, I would simply count the number of compatible properties, if there's only one, assign it directly, and if there are more than one, display the list.

Sounds good, but would it be ok if it still used Control, but to bypass the menu instead? So the behavior would be: show list of properties if there is more than 1 or don't show it if there is one property or Ctrl is held. This way it would be still possible to quick-assign something even if there are more slots (and we just assume that the first one is most common to use).

[groud]

This way it would be still possible to quick-assign something even if there are more slots (and we just assume that the first one is most common to use).

Hmm, I am not against the idea. But my issue with it is that I am not sure we kind of respect the fact that the "most expected property" always comes first. So I think it might be simpler to display the list in any case, to avoid frustrating users. As the supposed "most expected property" would be the first entry in the list, it's a simple one click more.

If we don't want to have this one more click, another solution might be to display the list, but if you don't click, or click elsewhere, it would assign it to the first property anyway. In such case, it could display something like "(default)" next to the first property in the list to make it clearer it would be assigned anyway.

[KoBeWi]

Ok, removed the Ctrl. The list will appear automatically when there's multiple allowed properties.

[akien-mga]

Thanks!

[akien-mga]

Cherry-picked for 3.4.

[akien-mga]

Cherry-picked for 3.4.

Actually not, there are too many uses of 4.x specific APIs in this commit, it would require a manual backport.