This adds the ability to switch between different application-configurations
without interfering with Blender's normal operation.
This commit doesn't include any templates,
so its mostly to allow collaboration for the Blender 101 project
and other custom configurations.
Application templates can be installed & selected from the file menu.
Other details:
- The `bl_app_template_utils` module handles template activation
(similar to `addon_utils`).
- The `bl_app_override` module is a general module
to assist scripts overriding parts of Blender in reversible way.
See docs:
https://docs.blender.org/manual/en/dev/advanced/app_templates.html
See patch: D2565
No reason to not make this private to this file, and it gave conflict
when using bpy as module and loading it in a GLib application (which
also has a g_atexit var).
BKE_main_id_tag_/BKE_main_id_flag_ were horrible naming now that we split those
into flags (for presistent one) and tags (for runtime ones).
Got rid of previous 'tag_' functions behavior (those who were dedicated shortcuts
to set/clear LIB_TAG_DOIT), so now '_tag_' functions affect tags, and '_flag_'
functions affect flags.
This is purely internal sanitizing/cleanup, no change in behavior is expected at all.
This change was also needed because we were getting short on ID flags, and
future enhancement of 'user_one' ID behavior requires two new ones.
id->flag remains for persistent data (fakeuser only, so far!), this also allows us
100% backward & forward compatibility.
New id->tag is used for most flags. Though written in .blend files, its content
is cleared at read time.
Note that .blend file version was bumped, so that we can clear runtimeflags from
old .blends, important in case we add new persistent flags in future.
Also, behavior of tags (either status ones, or whether they need to be cleared before/after use)
has been added as comments to their declaration.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1683
This commits does mostly two things:
* Get rid of bContext parameter: I can see no real good reason to pass such a high-level data
to such low-level code... It also makes it more difficult to call when you do not have
a context available.
* Cleanup the instantiating part.
Last point is the most risky - previous code was sometimes quite confusing and hard to follow,
from tests nothing behaves differently in new code, but some hidden corner case may show up.
Anyway, no change in behavior is expected from this commit, if it happens please file a bugreport!
Caused by changes in 31e26bb83b. This makes it fall back to the old
method if we can't find a screen.
Patch is actually by @LazyDodo with minor edits by me.
Using different scenes with 2+ windows broke entirely using undo.
Now keep track of the current windows scene in each undo-file,
and ensure the undo-scene is on a visible window when undo is executed,
switching the scene only when its not in a visible window.
