archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
f5a471ef865dcbd0807c7b4ff71825d288b66453
blender-archive/release/scripts/modules/nodeitems_utils.py

173 lines
5.3 KiB
Python
Raw Normal View History

Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
# ##### BEGIN GPL LICENSE BLOCK #####
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software Foundation,
# Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
#
# ##### END GPL LICENSE BLOCK #####
# <pep8 compliant>
import bpy
cleanup: pep8 also remove empty class parenthesis
2015-01-29 15:35:06 +11:00
class NodeCategory:
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
@classmethod
def poll(cls, context):
return True
A bit more pythonic way of using the items callback in node categories. The category.items attribute is now a function taking a context parameter instead of a property. This can be used for checking validity, e.g. for doing node group recursion checks, and filter out unusable items.
2013-05-08 15:41:05 +00:00
def __init__(self, identifier, name, description="", items=None):
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
self.identifier = identifier
self.name = name
self.description = description
A bit more pythonic way of using the items callback in node categories. The category.items attribute is now a function taking a context parameter instead of a property. This can be used for checking validity, e.g. for doing node group recursion checks, and filter out unusable items.
2013-05-08 15:41:05 +00:00
if items is None:
self.items = lambda context: []
elif callable(items):
self.items = items
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
else:
Fix for node menu: Show the group input/output nodes in the Input/Output categories respectively, so they can be added with the usual UI in case the user deletes them. These nodes are polled out for non-group trees (node trees not in the bpy.data.node_groups collection) to avoid confusion. For that purpose a new optional poll function argument has been added to NodeItem, which allows selectively polling individual items in an otherwise static list.
2013-05-28 09:45:34 +00:00
def items_gen(context):
for item in items:
Fix T44822: python enums' itemf callback did not handle 'NULL' context case. Enum's itemf callback can be called without context in some cases (UI, doc generation...). Python's enum properties did not handle this at all - it's kind of odd this did not cause more trouble and wasn't notice earlier... Probably dynamic enums using context are not much used in py code. Note about nodes: those are heavy users of dynamic enum with context. Now, we expect `NodeCategory.poll()` and `NodeItem.poll()` to always be called with a valid context (since when there is no context available, we can assume `poll()` is always True). `NodeCategory.items()`, however, must accept NULL context, so if you use custom `items` callable for your custom node categories, you may need to update it (as was done here for builtin `node_group_items()`).
2015-05-25 14:19:51 +02:00
if item.poll is None or context is None or item.poll(context):
Fix for node menu: Show the group input/output nodes in the Input/Output categories respectively, so they can be added with the usual UI in case the user deletes them. These nodes are polled out for non-group trees (node trees not in the bpy.data.node_groups collection) to avoid confusion. For that purpose a new optional poll function argument has been added to NodeItem, which allows selectively polling individual items in an otherwise static list.
2013-05-28 09:45:34 +00:00
yield item
self.items = items_gen
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
pep8 cleanup
2013-06-27 03:05:19 +00:00
cleanup: pep8 also remove empty class parenthesis
2015-01-29 15:35:06 +11:00
class NodeItem:
Python: avoid mutable default param values D1328 by @yedpodtrzitko
2015-05-31 15:56:22 +10:00
def __init__(self, nodetype, label=None, settings=None, poll=None):
if settings is None:
settings = {}
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
self.nodetype = nodetype
self._label = label
self.settings = settings
Fix for node menu: Show the group input/output nodes in the Input/Output categories respectively, so they can be added with the usual UI in case the user deletes them. These nodes are polled out for non-group trees (node trees not in the bpy.data.node_groups collection) to avoid confusion. For that purpose a new optional poll function argument has been added to NodeItem, which allows selectively polling individual items in an otherwise static list.
2013-05-28 09:45:34 +00:00
self.poll = poll
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
@property
def label(self):
if self._label:
return self._label
else:
# if no custom label is defined, fall back to the node type UI name
return getattr(bpy.types, self.nodetype).bl_rna.name
Fix #35633, Cannot Add Group Node In Blender 2.67a. The menu entry for the "make group" operator was missing in the new categories system. Added an alternative NodeItemCustom to the standard NodeItem to allow custom draw functions such as this operator. Used in the group items callback to generate the basic group_make operator call.
2013-06-05 09:21:17 +00:00
# NB: is a staticmethod because called with an explicit self argument
# NodeItemCustom sets this as a variable attribute in __init__
@staticmethod
def draw(self, layout, context):
default_context = bpy.app.translations.contexts.default
props = layout.operator("node.add_node", text=self.label, text_ctxt=default_context)
props.type = self.nodetype
props.use_transform = True
for setting in self.settings.items():
ops = props.settings.add()
ops.name = setting[0]
ops.value = setting[1]
cleanup: pep8 also remove empty class parenthesis
2015-01-29 15:35:06 +11:00
class NodeItemCustom:
Fix #35633, Cannot Add Group Node In Blender 2.67a. The menu entry for the "make group" operator was missing in the new categories system. Added an alternative NodeItemCustom to the standard NodeItem to allow custom draw functions such as this operator. Used in the group items callback to generate the basic group_make operator call.
2013-06-05 09:21:17 +00:00
def __init__(self, poll=None, draw=None):
self.poll = poll
self.draw = draw
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
Nicer registration mechanism for node categories. The lists of node categories and items are now stored in a dictionary with an identifier key, so they can be registered and unregistered individually. The Add menu is now persistent and gets extended with a draw function for each of the registered node category lists. This allows pynodes to define their own list of node categories and items and register it at runtime without interfering with the standard nodes.
2013-04-22 16:25:35 +00:00
_node_categories = {}
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
pep8 cleanup
2013-06-27 03:05:19 +00:00
Nicer registration mechanism for node categories. The lists of node categories and items are now stored in a dictionary with an identifier key, so they can be registered and unregistered individually. The Add menu is now persistent and gets extended with a draw function for each of the registered node category lists. This allows pynodes to define their own list of node categories and items and register it at runtime without interfering with the standard nodes.
2013-04-22 16:25:35 +00:00
def register_node_categories(identifier, cat_list):
if identifier in _node_categories:
raise KeyError("Node categories list '%s' already registered" % identifier)
return
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
# works as draw function for both menus and panels
def draw_node_item(self, context):
layout = self.layout
Node Toolbar: * Use column() layout, this way it uses a bit less space.
2013-04-14 09:17:03 +00:00
col = layout.column()
A bit more pythonic way of using the items callback in node categories. The category.items attribute is now a function taking a context parameter instead of a property. This can be used for checking validity, e.g. for doing node group recursion checks, and filter out unusable items.
2013-05-08 15:41:05 +00:00
for item in self.category.items(context):
Fix #35633, Cannot Add Group Node In Blender 2.67a. The menu entry for the "make group" operator was missing in the new categories system. Added an alternative NodeItemCustom to the standard NodeItem to allow custom draw functions such as this operator. Used in the group items callback to generate the basic group_make operator call.
2013-06-05 09:21:17 +00:00
item.draw(item, col, context)
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
Nicer registration mechanism for node categories. The lists of node categories and items are now stored in a dictionary with an identifier key, so they can be registered and unregistered individually. The Add menu is now persistent and gets extended with a draw function for each of the registered node category lists. This allows pynodes to define their own list of node categories and items and register it at runtime without interfering with the standard nodes.
2013-04-22 16:25:35 +00:00
menu_types = []
panel_types = []
for cat in cat_list:
pep8 cleanup
2013-06-27 03:05:19 +00:00
menu_type = type("NODE_MT_category_" + cat.identifier, (bpy.types.Menu,), {
"bl_space_type": 'NODE_EDITOR',
"bl_label": cat.name,
"category": cat,
"poll": cat.poll,
"draw": draw_node_item,
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
})
pep8 cleanup
2013-06-27 03:05:19 +00:00
panel_type = type("NODE_PT_category_" + cat.identifier, (bpy.types.Panel,), {
"bl_space_type": 'NODE_EDITOR',
"bl_region_type": 'TOOLS',
"bl_label": cat.name,
Use toolbar tabs for node categories instead of just a long list of panels. Patch by @Severin (with minor modifications by me). As discussed in {D535} the node editor does not have real modal operator tools like the 3D view or image editors for instance, so it makes sense to utilise it this way. Tabs really help in this area due to the large amount of node types and categories. Further tweaks could be made later if the need arises.
2014-06-23 16:34:02 +02:00
"bl_category": cat.name,
pep8 cleanup
2013-06-27 03:05:19 +00:00
"category": cat,
"poll": cat.poll,
"draw": draw_node_item,
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
})
Nicer registration mechanism for node categories. The lists of node categories and items are now stored in a dictionary with an identifier key, so they can be registered and unregistered individually. The Add menu is now persistent and gets extended with a draw function for each of the registered node category lists. This allows pynodes to define their own list of node categories and items and register it at runtime without interfering with the standard nodes.
2013-04-22 16:25:35 +00:00
menu_types.append(menu_type)
panel_types.append(panel_type)
bpy.utils.register_class(menu_type)
bpy.utils.register_class(panel_type)
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
def draw_add_menu(self, context):
layout = self.layout
Nicer registration mechanism for node categories. The lists of node categories and items are now stored in a dictionary with an identifier key, so they can be registered and unregistered individually. The Add menu is now persistent and gets extended with a draw function for each of the registered node category lists. This allows pynodes to define their own list of node categories and items and register it at runtime without interfering with the standard nodes.
2013-04-22 16:25:35 +00:00
for cat in cat_list:
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
if cat.poll(context):
layout.menu("NODE_MT_category_%s" % cat.identifier)
Nicer registration mechanism for node categories. The lists of node categories and items are now stored in a dictionary with an identifier key, so they can be registered and unregistered individually. The Add menu is now persistent and gets extended with a draw function for each of the registered node category lists. This allows pynodes to define their own list of node categories and items and register it at runtime without interfering with the standard nodes.
2013-04-22 16:25:35 +00:00
bpy.types.NODE_MT_add.append(draw_add_menu)
# stores: (categories list, menu draw function, submenu types, panel types)
_node_categories[identifier] = (cat_list, draw_add_menu, menu_types, panel_types)
Upgrade for the add_search node operator. This now uses the same basic system as the regular add_node operator, with enum items generated from the common node categories system (nodeitems_utils module). This means that any node listed in the regular node Add menu can now also be added via searching, including node groups and the like. The search operator also uses the subsequent transform to make insertion a bit more streamlined.
2013-05-09 11:43:48 +00:00
def node_categories_iter(context):
for cat_type in _node_categories.values():
for cat in cat_type[0]:
Fix T44822: python enums' itemf callback did not handle 'NULL' context case. Enum's itemf callback can be called without context in some cases (UI, doc generation...). Python's enum properties did not handle this at all - it's kind of odd this did not cause more trouble and wasn't notice earlier... Probably dynamic enums using context are not much used in py code. Note about nodes: those are heavy users of dynamic enum with context. Now, we expect `NodeCategory.poll()` and `NodeItem.poll()` to always be called with a valid context (since when there is no context available, we can assume `poll()` is always True). `NodeCategory.items()`, however, must accept NULL context, so if you use custom `items` callable for your custom node categories, you may need to update it (as was done here for builtin `node_group_items()`).
2015-05-25 14:19:51 +02:00
if cat.poll and ((context is None) or cat.poll(context)):
Upgrade for the add_search node operator. This now uses the same basic system as the regular add_node operator, with enum items generated from the common node categories system (nodeitems_utils module). This means that any node listed in the regular node Add menu can now also be added via searching, including node groups and the like. The search operator also uses the subsequent transform to make insertion a bit more streamlined.
2013-05-09 11:43:48 +00:00
yield cat
def node_items_iter(context):
for cat in node_categories_iter(context):
for item in cat.items(context):
yield item
Nicer registration mechanism for node categories. The lists of node categories and items are now stored in a dictionary with an identifier key, so they can be registered and unregistered individually. The Add menu is now persistent and gets extended with a draw function for each of the registered node category lists. This allows pynodes to define their own list of node categories and items and register it at runtime without interfering with the standard nodes.
2013-04-22 16:25:35 +00:00
def unregister_node_cat_types(cats):
bpy.types.NODE_MT_add.remove(cats[1])
for mt in cats[2]:
bpy.utils.unregister_class(mt)
for pt in cats[3]:
bpy.utils.unregister_class(pt)
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
Nicer registration mechanism for node categories. The lists of node categories and items are now stored in a dictionary with an identifier key, so they can be registered and unregistered individually. The Add menu is now persistent and gets extended with a draw function for each of the registered node category lists. This allows pynodes to define their own list of node categories and items and register it at runtime without interfering with the standard nodes.
2013-04-22 16:25:35 +00:00
def unregister_node_categories(identifier=None):
Replacing the node Add menu and making the toolbar useful As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading. To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py). There are a number of additional features that become possible with this implementation: 1) Node Toolbar can be populated! The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible. 2) Each node item is a true operator call. The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes. 3) Node Items support additional settings. Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C. 4) Node items can be generated with a function. A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image. WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
2013-04-13 15:38:02 +00:00
# unregister existing UI classes
Nicer registration mechanism for node categories. The lists of node categories and items are now stored in a dictionary with an identifier key, so they can be registered and unregistered individually. The Add menu is now persistent and gets extended with a draw function for each of the registered node category lists. This allows pynodes to define their own list of node categories and items and register it at runtime without interfering with the standard nodes.
2013-04-22 16:25:35 +00:00
if identifier:
cat_types = _node_categories.get(identifier, None)
if cat_types:
unregister_node_cat_types(cat_types)
del _node_categories[identifier]
else:
for cat_types in _node_categories.values():
unregister_node_cat_types(cat_types)
_node_categories.clear()
Copy Permalink