Change Details

NOTE: WIP... This task is to design and keep track of how the new Draft system will be implemented as part of the new Brush Asset system. Draft is a special, per-user .blend file, which can be edited by Blender while other (regular) blend files are opened, It acts as some sort of powerful non-volatile copy/paste buffer, and is based on the Asset library system. Draft Basics ========= Some key characteristics: * Draft is a .blend file in the usersettings path. * Data should never be (permanently) linked from Draft. Runtime-only linking is allowed (not directly by the user though), as well as appending. * Only assets are accessible from the Draft, through the Asset system. There is no direct 'low-level' appending/linking possible for the user. Blender needs to be able to: * Open a .blend file in a secondary Main, different than the current active one. * Manipulate data-blocks in that secondary Main (on a basic level: Move IDs between Mains, add/delete IDs in secondary main, ...). * Save a secondary Main into a .blend file. * A locking mechanism is likely mandatory, to prevent several instances of Blender modifying the Draft file simultaneously. //Maybe simply an additional `draft.blend.lock` empty file alongside the `draft.blend` one?// Some open questions: * Is Draft fully independent, or can it use linking from other sources (e.g. dependencies from Brushes, like textures, could be linked from the original asset repository file)? //Probably fully independent would be simpler and safer. On the other end, it means there would be no storing of overrides in the draft, which is quite an important limitation).// ** If Draft is not fully self-contained. how do we handle paths to linked IDs and non-embedded data (like images)? //Current idea would be to store paths relative to the draft file itself. That way, draft can be e.g. synced or shared between different systems as long as the relative directory layout of draft and asset repositories still matches. // * Are more than one Draft repository supported? E.g. 'projects' could also have their own Draft? * Different instances of Blender need to update automatically on Draft changes. This probably implies (re-)investigating FS change events API for our GHOST (integrating `inotify` on linux, `fsevents` on OSX, etc.)? Needs to be its own design task. * There is most likely needs for some level of management on the Draft. ** Cleaning up unused non-asset IDs. Manually or automatically? ** Deleting some assets? ** Purging (deleting everything)? ** ... Brush Handling in Draft ================== The handling of brushes in Draft is not directly exposed to the user, they only interact with the Draft through a limited set of higher level operations. Draft has two main purposes: * To allow user to store their tweaked/modified versions of Brushes from (readonly) asset libraries. * As the source of data when authoring an asset library, when user want to publish their modified brush assets. Save & Save As ------------------ Save and Save As store a liboverride of the original brush asset in the draft. That way, non-edited settings still get updated in case the original asset data is updated. In that case, dependency IDs (textures etc.) are not stored in the Draft, they are still linked from the asset repository. unless they were made local already in the working .blend file. Paths to linked IDs are relative to the Draft .blend file. Save will update an existing override in the draft, if any. Save As always create a new override with a new name (or replace an existing one in case of name collision). Meta data of the new draft asset are copied from the original linked asset. Duplicate ----------- Duplicate stores a fully independent copy of the original brush asset and its dependencies into the Draft. //Do we also need 'Duplicate As'? Or is Duplicate always 'as' since we never overwrite and existing ID in Draft in that case?// Handling of dependencies ID is similar to `append or reuse` (i.e. if a coy of the original linked ID is already found in the Draft, it is reused). Using Draft Asset -------------------- Using a Draft Brush happens exactly as any other brush asset. Importing From - AKA Publishing --------------------------------------- To 'publish' a draft asset, user 'append or reuse' it into their asset library file. They can then edit it as any regular asset. Draft Beyond Brushes ================= While this is not a target for the Brush Asset project, Draft usage could be generalized to any type of data that can become an asset, and be used as an advanced copy/stage/paste buffer.

NOTE: WIP... This task is to design and keep track of how the new Draft system will be implemented as part of the new Brush Asset system. Draft is a special, per-user .blend file, which can be edited by Blender while other (regular) blend files are opened, It acts as some sort of powerful non-volatile copy/paste buffer, and is based on the Asset library system. Draft Basics ========= Some key characteristics: * Draft is a .blend file in the usersettings path. * Data should never be (permanently) linked from Draft. Runtime-only linking is allowed (not directly by the user though), as well as appending. * Only assets are accessible from the Draft, through the Asset system. There is no direct 'low-level' appending/linking possible for the user. Blender needs to be able to: * Open a .blend file in a secondary Main, different than the current active one. * Manipulate data-blocks in that secondary Main (on a basic level: Move IDs between Mains, add/delete IDs in secondary main, ...). * Save a secondary Main into a .blend file. * A locking mechanism is likely mandatory, to prevent several instances of Blender modifying the Draft file simultaneously. //Maybe simply an additional `draft.blend.lock` empty file alongside the `draft.blend` one?// Some open questions: * Is Draft fully independent, or can it use linking from other sources (e.g. dependencies from Brushes, like textures, could be linked from the original asset repository file)? //Probably fully independent would be simpler and safer. On the other end, it means there would be no storing of overrides in the draft, which is quite an important limitation).// ** If Draft is not fully self-contained. how do we handle paths to linked IDs and non-embedded data (like images)? //Current idea would be to store paths relative to the draft file itself. That way, draft can be e.g. synced or shared between different systems as long as the relative directory layout of draft and asset repositories still matches. // * Are more than one Draft repository supported? E.g. 'projects' could also have their own Draft? * Different instances of Blender need to update automatically on Draft changes. This probably implies (re-)investigating FS change events API for our GHOST (integrating `inotify` on linux, `fsevents` on OSX, etc.)? Needs to be its own design task. * There is most likely needs for some level of management on the Draft. ** Cleaning up unused non-asset IDs. Manually or automatically? ** Deleting some assets? ** Purging (deleting everything)? ** ... Brush Handling in Draft ================== The handling of brushes in Draft is not directly exposed to the user, they only interact with the Draft through a limited set of higher level operations. Draft has two main purposes: * To allow user to store their tweaked/modified versions of Brushes from (readonly) asset libraries. * As the source of data when authoring an asset library, when user want to publish their modified brush assets. Save & Save As ------------------ Save and Save As store a liboverride of the original brush asset in the draft. That way, non-edited settings still get updated in case the original asset data is updated. In that case, dependency IDs (textures etc.) are not stored in the Draft, they are still linked from the asset repository. unless they were made local already in the working .blend file. Paths to linked IDs are relative to the Draft .blend file. Save will update an existing override in the draft, if any. Save As always create a new override with a new name (or replace an existing one in case of name collision). Meta data of the new draft asset are copied from the original linked asset. Duplicate ----------- Duplicate stores a fully independent copy of the original brush asset and its dependencies into the Draft. //Do we also need 'Duplicate As'? Or is Duplicate always 'as' since we never overwrite and existing ID in Draft in that case?// Handling of dependencies ID is similar to `append or reuse` (i.e. if a copy of the original linked ID is already found in the Draft, it is reused). Using Draft Asset -------------------- Using a Draft Brush happens exactly as any other brush asset. Importing From - AKA Publishing --------------------------------------- To 'publish' a draft asset, user 'append or reuse' it into their asset library file. They can then edit it as any regular asset. Draft Beyond Brushes ================= While this is not a target for the Brush Asset project, Draft usage could be generalized to any type of data that can become an asset, and be used as an advanced copy/stage/paste buffer.

NOTE: WIP... This task is to design and keep track of how the new Draft system will be implemented as part of the new Brush Asset system. Draft is a special, per-user .blend file, which can be edited by Blender while other (regular) blend files are opened, It acts as some sort of powerful non-volatile copy/paste buffer, and is based on the Asset library system. Draft Basics ========= Some key characteristics: * Draft is a .blend file in the usersettings path. * Data should never be (permanently) linked from Draft. Runtime-only linking is allowed (not directly by the user though), as well as appending. * Only assets are accessible from the Draft, through the Asset system. There is no direct 'low-level' appending/linking possible for the user. Blender needs to be able to: * Open a .blend file in a secondary Main, different than the current active one. * Manipulate data-blocks in that secondary Main (on a basic level: Move IDs between Mains, add/delete IDs in secondary main, ...). * Save a secondary Main into a .blend file. * A locking mechanism is likely mandatory, to prevent several instances of Blender modifying the Draft file simultaneously. //Maybe simply an additional `draft.blend.lock` empty file alongside the `draft.blend` one?// Some open questions: * Is Draft fully independent, or can it use linking from other sources (e.g. dependencies from Brushes, like textures, could be linked from the original asset repository file)? //Probably fully independent would be simpler and safer. On the other end, it means there would be no storing of overrides in the draft, which is quite an important limitation).// ** If Draft is not fully self-contained. how do we handle paths to linked IDs and non-embedded data (like images)? //Current idea would be to store paths relative to the draft file itself. That way, draft can be e.g. synced or shared between different systems as long as the relative directory layout of draft and asset repositories still matches. // * Are more than one Draft repository supported? E.g. 'projects' could also have their own Draft? * Different instances of Blender need to update automatically on Draft changes. This probably implies (re-)investigating FS change events API for our GHOST (integrating `inotify` on linux, `fsevents` on OSX, etc.)? Needs to be its own design task. * There is most likely needs for some level of management on the Draft. ** Cleaning up unused non-asset IDs. Manually or automatically? ** Deleting some assets? ** Purging (deleting everything)? ** ... Brush Handling in Draft ================== The handling of brushes in Draft is not directly exposed to the user, they only interact with the Draft through a limited set of higher level operations. Draft has two main purposes: * To allow user to store their tweaked/modified versions of Brushes from (readonly) asset libraries. * As the source of data when authoring an asset library, when user want to publish their modified brush assets. Save & Save As ------------------ Save and Save As store a liboverride of the original brush asset in the draft. That way, non-edited settings still get updated in case the original asset data is updated. In that case, dependency IDs (textures etc.) are not stored in the Draft, they are still linked from the asset repository. unless they were made local already in the working .blend file. Paths to linked IDs are relative to the Draft .blend file. Save will update an existing override in the draft, if any. Save As always create a new override with a new name (or replace an existing one in case of name collision). Meta data of the new draft asset are copied from the original linked asset. Duplicate ----------- Duplicate stores a fully independent copy of the original brush asset and its dependencies into the Draft. //Do we also need 'Duplicate As'? Or is Duplicate always 'as' since we never overwrite and existing ID in Draft in that case?// Handling of dependencies ID is similar to `append or reuse` (i.e. if a copy of the original linked ID is already found in the Draft, it is reused). Using Draft Asset -------------------- Using a Draft Brush happens exactly as any other brush asset. Importing From - AKA Publishing --------------------------------------- To 'publish' a draft asset, user 'append or reuse' it into their asset library file. They can then edit it as any regular asset. Draft Beyond Brushes ================= While this is not a target for the Brush Asset project, Draft usage could be generalized to any type of data that can become an asset, and be used as an advanced copy/stage/paste buffer.