Previously, it was possible for the number of stored columns per table to grow
unbounded. While this likely isn't a problem in practice in most cases, one can
imagine cases where people temporarily have thousands of attributes when are
then never used again. We shouldn't have to store any data for these columns
forever.
This patch adds some simple garbage collection mechanism that keeps the number
of stored unavailable columns per spreadsheet table below a certain threshold
(50 currently). Least recently used columns are removed first.
Pull Request: https://projects.blender.org/blender/blender/pulls/139469
The main goal of this patch is that the column widths and ordering is not reset
every time one switches between different contexts.
It does that by keeping track of multiple `SpreadsheetTable`. There is one for
each table that is viewed (so e.g. the point and edge domain of the same mesh
are two different tables). Each table has an identifier and an array of columns.
There is some garbage collection in place so that the number of stored tables
does not increase unbounded.
This also comes with an updated Python API:
```python
import bpy
spreadsheet = bpy.context.screen.areas[...].spaces.active
active_table = spreadsheet.tables.active
print(active_table.id.type)
print(active_table.id.attribute_domain)
print(active_table.columns[0].id.name)
```
In the future, we might add some smarter logic to keep tables with different
identifiers more in sync. We don't have a great heuristic for that yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/139205
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
This patch adds support for _Menu Switch_ nodes and enum definitions in
node trees more generally. The design is based on the outcome of the
[2022 Nodes Workshop](https://code.blender.org/2022/11/geometry-nodes-workshop-2022/#menu-switch).
The _Menu Switch_ node is an advanced version of the _Switch_ node which
has a customizable **menu input socket** instead of a simple boolean.
The _items_ of this menu are owned by the node itself. Each item has a
name and description and unique identifier that is used internally. A
menu _socket_ represents a concrete value out of the list of items.
To enable selection of an enum value for unconnected sockets the menu is
presented as a dropdown list like built-in enums. When the socket is
connected a shared pointer to the enum definition is propagated along
links and stored in socket default values. This allows node groups to
expose a menu from an internal menu switch as a parameter. The enum
definition is a runtime copy of the enum items in DNA that allows
sharing.
A menu socket can have multiple connections, which can lead to
ambiguity. If two or more different menu source nodes are connected to a
socket it gets marked as _undefined_. Any connection to an undefined
menu socket is invalid as a hint to users that there is a problem. A
warning/error is also shown on nodes with undefined menu sockets.
At runtime the value of a menu socket is the simple integer identifier.
This can also be a field in geometry nodes. The identifier is unique
within each enum definition, and it is persistent even when items are
added, removed, or changed. Changing the name of an item does not affect
the internal identifier, so users can rename enum items without breaking
existing input values. This also persists if, for example, a linked node
group is temporarily unavailable.
Pull Request: https://projects.blender.org/blender/blender/pulls/113445
