When dropping asset objects, place them under the mouse-cursor
along with any other objects they link in.
Note that there are quite a few changes/refactor that would be worth doing to make this work better, initially I looked into passing ID's from link/append to the caller so they could be manipulated - but this ended up having to access window->eventstate.x/y to position the object (which isn't so elegant). See P2519.
This patch aims to support this functionality in the least disruptive way (to simplify review and to see if the approach is worth pursuing further).
Further Work
- Use two separate drop handlers instead of using OBJECT_OT_add_named only to place existing objects. One drop handler would deal with ID's (the outliner) the other would deal with assets. This way OBJECT_OT_add_named need not have the only_place option added.
- OBJECT_OT_add_named "duplicate" option can be removed.
Notes
- Operating on the resulting selection after appending has the potential downside that newly created data can't be selected or edited (is hidden for example). Committed rB3a2b7f35f469: LibLink: ensure objects are selectable when "Select" is enabled so all newly appended objects are visible & selectable, nevertheless, this is a weakness in this patch and we might consider supporting returning multiple ID's so they can be handled reliably.
- T92111 notes that the repositioning should be done in IDTypeInfo.make_local().
I'm not sure how this would work as positioning objects may be assigning the position of multiple root-level parent objects, where only the parents should be moved. Which object is/isn't a root depends on knowing which objects are being transformed - which seems to high level for IDTypeInfo.make_local().
- Properly knowing the object location may depend on evaluating the depsgraph (the object could be animated - or use constraints). This is currently done in this patch so the final (appended) location of the object is known before that is used as a reference to move it to it's new location.
We could consider this unimportant and use lower level object placement (e.g. see P2519 which assumed Object.obmat are up to date). But I think it's better to avoid any discrepancy between the position of the object in it's source file - and it's position once linked/appended.
- Snap logic is used to translate the objects, to avoid duplicating code (committed separately rB2bcf93bbbeb9: View3D: expose snap selection as a utility funciton).