Page MenuHome

Outliner: fix DragDrop materials to objects inconsistency
AbandonedPublic

Authored by Sergey Sharybin (sergey) on Jan 30 2015, 1:24 PM.

Details

Summary

while working on the outliner (specifically D992: Outliner: DragDrop materials to groups (to assign material to every group member)), I came across an inconsistency when linking of materials to objects. atm we have the following behaviour:

(1) CTRL+L > Materials:
assigns/overwrites the material to the first material slot

(2) drag n drop from/to the outliner:
create new material slot and assign to this

(3) drag n drop from the outliner to 3DView:
assigns/overwrites the material to the first material slot

So this patch will make it so (2) acts as (1) and (3).
I really dont see the reasoning to not have this consistent (even though the original commit message explictly mentions this: "Adds the material at materials + 1 unlike the DnD view3d one which replaces the first one"...)

had a quick about this with ideasman42 in IRC and at first glance this was his answer there...
<lichtwerk> while we are at it: what do you think about the consistency in dnd material>>object (see https://developer.blender.org/D992)?
<ideasman42> probably these should both work the same way
<ideasman42> I expect this is just sloppy design

Diff Detail

Event Timeline

Philipp Oeser (lichtwerk) retitled this revision from to Outliner: fix DragDrop materials to objects inconsistency.
Philipp Oeser (lichtwerk) updated this object.
This revision is now accepted and ready to land.Feb 4 2015, 5:50 PM

Sorry to backflip on this one.

But while checking the path I think the current behavior makes some sense.

Drag and drop adds a new material. (Just as it adds children to a parent for eg).

So it makes some sense that dragging a material onto a mesh adds a new slot. Whereas linking is a way to match the material to the active object.

Leaving open for feedback but think this could be left the way it is (With some comment in outliner_edit.c explaining why it works this way).

This revision now requires review to proceed.Feb 5 2015, 10:02 AM

well, I guess both sides have some sense to it... [my personal intuition would still be: "what you Drag-n-drop has some sort of priority over preexisting state, it will change the current state, rather than just adding to the basket of what was there before" -- but like I said: personal opinion, and not a strong opinion in this case...]

But anyway, if we stick with "Drag and drop adds a new material. (Just as it adds children to a parent for eg)." like you suggested then we should change the behaviour of drag-n-drop a material to 3DView [(3) from my first post]?
In any way (2) and (3) from my first post should be consistent, dont you think [which they are not atm...]?

maybe we should do something like "Add Material to new material slot (Ctrl for using first slot)"? Similar to what we do for drag-n-drop Adding Background Image?
So user has the choice?

I wouldn't really suggest using the modifier keys to control behavior. It's just becoming more complicated interaction. Current behavior seems totally logical because you're just adding new material. For something more advanced just go to the Material buttons. we can't handle all possible things you want to tweak via modifier keys anyway.

We discussed it with Campbell and agree that such change would not really be in master.. So closing the revision.

fair enough, lets move on :)