Unify link/append between WM operators and BPY context manager API, and cleanup usages of BKE_library_make_local #91414

New Issue

Bastien Montagne · 2021-09-14T18:16:26+02:00

Bastien Montagne commented

2021-09-14 18:16:26 +02:00

Recent refactor of Append code in WM operators left bpy API and copy/paste code untouched. Those three code paths need to be unified, they are essentially doing the same thing, there is no reason to have them separated in the first place.

Proposal

Step 1: Reorganization

Move most of 'internal' link/append code from wm_files_link.c to a new BKE_blendfile_link_append.h/intern/blendfile_link_append.c, including:

wm_do_link, wm_do_append, and their dependencies;
the WMLinkAppendData/Item structures (which should be 'private', i.e. only defined in implementation) and their API (to be made public).
** WMLinkAppendData could be renamed BlendfileLinkAppendContext e.g.
D13222: Link/Append: Move most of core link/append code from WM to new BKE_blendflie_link_append module., fe274d91a1

This will allow any code to have access to the advanced linking and appending features currently only available in WM (e.g. copy/paste code, or the python API): fine control over link/append behavior, handling of several IDs from potentially several libraries at the same time, etc.

Step 2: De-duplication

Make all link/append code use this new BKE API:
- Handle instantiation of objects etc. in link case in BKE_blender_link_append code (was already done for append in wm_append_do). d7cf7d4048
- Rewrite bpy's bpy.data.libraries.load() exit function to use BKE's link/append code. D13331: LibLink/Append: Port bpy.data.libraries.load to new BKE_blendfile_link_append module., 0704570721
- Rewrite paste code. b9f54dd48a, 3f08488244.

Remove 'append' usages of BKE_library_make_local.
Remove all direct usages of BLO linking code (unless this very basic behavior - only linking from a single library - is good enough. But don't think it would be for any current usecases).

Step 3: Code Removal

~~Simplify BKE_library_make_local to make it only handle the actual 'make local' case (i.e. when a user wants to manually make local a datablock after they have linked it, or a whole library).~~ not much to do here actually, we could simplify a bit the signature of the function, but not really its content.
Remove instantiation code from BLO. 9f290467ca 4fe8c62b56
This is not the place for such code. It is only used currently in linking case, in append case it was already moved to wm_append_do and would now be handled by the new BKE_blender_link_append module.
** In BLO it lacks some high-level context information to get proper refined and controllable handling in all possible usecases.

Notes and references

ref. 3be5ce4aad for the initial new append code.

Recent refactor of Append code in WM operators left bpy API and copy/paste code untouched. Those three code paths need to be unified, they are essentially doing the same thing, there is no reason to have them separated in the first place. Proposal **** Step 1: Reorganization -------------------------- - [x] Move most of 'internal' link/append code from `wm_files_link.c` to a new `BKE_blendfile_link_append.h`/`intern/blendfile_link_append.c`, including: * `wm_do_link`, `wm_do_append`, and their dependencies; * the `WMLinkAppendData/Item` structures (which should be 'private', i.e. only defined in implementation) and their API (to be made public). ** `WMLinkAppendData` could be renamed `BlendfileLinkAppendContext` e.g. * [D13222: Link/Append: Move most of core link/append code from WM to new `BKE_blendflie_link_append` module.](https://archive.blender.org/developer/D13222), fe274d91a1 This will allow any code to have access to the advanced linking and appending features currently only available in WM (e.g. copy/paste code, or the python API): fine control over link/append behavior, handling of several IDs from potentially several libraries at the same time, etc. Step 2: De-duplication -------------------------- - [x] Make all link/append code use this new BKE API: - [x] Handle instantiation of objects etc. in link case in `BKE_blender_link_append` code (was already done for append in `wm_append_do`). d7cf7d4048 - [x] Rewrite bpy's `bpy.data.libraries.load()` exit function to use BKE's link/append code. [D13331: LibLink/Append: Port `bpy.data.libraries.load` to new `BKE_blendfile_link_append` module.](https://archive.blender.org/developer/D13331), 0704570721 - [x] Rewrite paste code. b9f54dd48a, 3f08488244. * Remove 'append' usages of `BKE_library_make_local`. * Remove all direct usages of `BLO` linking code (unless this very basic behavior - only linking from a single library - is good enough. But don't think it would be for any current usecases). Step 3: Code Removal ------------------------- - [x] ~~Simplify `BKE_library_make_local` to make it only handle the actual 'make local' case (i.e. when a user wants to manually make local a datablock after they have linked it, or a whole library).~~ *not much to do here actually, we could simplify a bit the signature of the function, but not really its content.* - [x] Remove instantiation code from `BLO`. 9f290467ca 4fe8c62b56 **This is not the place for such code.** It is only used currently in linking case, in append case it was already moved to `wm_append_do` and would now be handled by the new `BKE_blender_link_append` module. ** In BLO it lacks some high-level context information to get proper refined and controllable handling in all possible usecases. Notes and references **** ref. 3be5ce4aad for the initial new append code.

Bastien Montagne self-assigned this 2021-09-14 18:16:26 +02:00

Bastien Montagne commented

2021-09-14 18:16:26 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'