[Bf-committers] design question

[joe]

ah well many of the code implementation for e.g. meshes, textures, whatever
does have unlinking functions.  it'd mostly be a matter of reorganizing the
code to be more generalized.  also those algorithms tend to be fairly slow,
since they usually have to go through every single other block in the .blend
file that might reference the block it's trying to remove, to check them.

On Tue, Sep 9, 2008 at 11:17 AM, José Ignacio <jose.cyborg at gmail.com> wrote:

> > Um inherent in the design, you cannot delete a libblock without unlinking
> it
> > (e.g. so it's user counter (id.us) reaches 0).
> >
> > The original system of not deleting blocks immediately on user count
> > reaching zero was originally used as an undo mechanism, and I think is
> still
> > somewhat useful.  Instead their simply not saved to the .blend file.
> >
> > Joe
>
> well but sometimes is usefult to remove a block that has many users
> (and maybe some users cant be found easily) so a manual remove would
> be useful (it would be an auto unlink and removing the block) also
> maybe a merge option, to merge duplicated blocks without having to do
> it user by user (control-c sometimes doesnt help), i think both tasks
> can be done via scripts. also, with a manual delete mechanism,
> automatic remove of unused blocks may be disabled, maybe putting it as
> a button "remove unused blocks"
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20080909/b5ce2a1e/attachment.htm