[Bf-committers] About linked IDs, make_local() and extern/indirect tags...

[Campbell Barton]

On Mon, Jul 11, 2016 at 1:29 AM, Bastien Montagne <montagne29 at wanadoo.fr> wrote:
> Hey devs,
>
> As you may have noticed (lol), I’ve been rampaging past days in some
> ID-management BKE areas (mostly, make_local one, but also copy to some
> extent), and I have a question about politics of id_lib_extern usage.
>
> To summarize, when we make a datablock local, we have to tag all
> (linked) IDs it uses as 'extern' (and no more 'indirect') ones. So far,
> code mostly only tags 'refcounted' usages as extern (e.g. if you make an
> object local, all possible linked objects used as targets by its
> constraints/modifiers *will not* be tagged as 'extern' and will remain
> 'indirect').
>
> I cannot see any reason for this behavior, which only has a few
> exceptions like meshes' uvface/uvpoly images. To me it actually looks
> like a bug, since it means some non-refcounted usages may be lost at
> write/readfile time. Further more, there are some inconsistencies, e.g.
> BKE_camera_copy makes its dof_ob extern, while BKE_camera_make_local
> does not 'externalize' any pointer...
>
> So question is: are you aware of any historical reason explaining that
> behavior? Is it still desired, or can we switch to a simple
> full-externalize callback here (for both copy and make_local funcs)?
>
> Best regards,
> Bastien
>
> PS: I know the 'object targets of constraints/modifiers' in not a good
> example in practice, since objects are supposed to always be
> instantiated in scenes (i.e. always be 'extern' ones).

I'm not aware of any reasons not to make the data extern (in the common cases).

The only reason I can think of is for cases where you might indirectly
reference many data-blocks, where making local end up linking in a lot
of data.

For example an action with many drivers, referencing scenes scenes
from other files...
its correct but possible the users prefer the scene is swapped with
the current active scene, for eg.

Even so, think its fine to use a callback which covers all data types.
If it makes sense to exclude some links ~ it could be solved case-by-case.