Avoids repeated and redundant lookups. Also simplifies some code.
Note that currently, these drop targets are volatile objects created whenever
needed, but not kept in memory. Should they ever be kept over multiple redraws,
this view item reference will have to be updated for each.
Custom drop targets for views are supposed to use `DropTargetInterface` as the
base class, and view items `TreeViewItemDropTarget`. Light linking used
`TreeViewItemDropTarget` for both the view and the view item drop targets. This
is because they both used the same intermediate base class.
After suggestion from Sergey, this uses composition instead of multiple
inheritance, so `CollectionDropTarget` becomes a member instead of a base
class.
Pull Request: https://projects.blender.org/blender/blender/pulls/113550
The order of collections in the light linking collection is important
as it is used for tie-breaking when the same object is reachable from
multiple linked collections with different light linking state.
This commit utilizes the generic tree view reordering operations to
allow insertion of elements to a specific location and to re-order
existing objects and collections in the light linking collection.
It is possible to re-order both collections and objects, even tough
re-ordering objects does not really make a difference for the light
linking behavior. It is not possible to place an object before
collections.
Pull Request: https://projects.blender.org/blender/blender/pulls/112849
This change makes it so the list interface in the properties panels looks
closer to things like shape keys, vertex groups and so on: there are two
buttons to add selected objects to the collection and remove active item
from the collection, as well as the "extra" drop down menu.
The add operator adds selected objects to the light linking collection
using the Include policy. For the light linking it means that the objects
are added as receivers that receive the light, and for the shadow linking
it means that objects are added as blockers which cast shadow from the
light.
The communication of the active list element is done via context property
similar to how it was done before. The difference is that these properties
are set on a parent of the list layout, which makes it so they are inherited
by the layout hierarchy needed to place the Remove button.
Pull Request: https://projects.blender.org/blender/blender/pulls/112713
There are a couple of functions that create rna pointers. For example
`RNA_main_pointer_create` and `RNA_pointer_create`. Currently, those
take an output parameter `r_ptr` as last argument. This patch changes
it so that the functions actually return a` PointerRNA` instead of using
the output parameters.
This has a few benefits:
* Output parameters should only be used when there is an actual benefit.
Otherwise, one should default to returning the value.
* It's simpler to use the API in the large majority of cases (note that this
patch reduces the number of lines of code).
* It allows the `PointerRNA` to be const on the call-site, if that is desired.
No performance regression has been measured in production files.
If one of these functions happened to be called in a hot loop where
there is a regression, the solution should be to use an inline function
there which allows the compiler to optimize it even better.
Pull Request: https://projects.blender.org/blender/blender/pulls/111976
- Use `this->` to access class methods.
- Follow style guide for class definition order.
- Avoid unnecessary namespace redefinition.
- Make data struct local to node interface file.
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
No user visible changes expected, these are just the internal API preparations.
Modifies the Drop API for views so that tree-views can choose to insert items
before, after and into other items.
Note: While there is support for drag-tooltips that can explain how an item
will be inserted, there is no drawing yet like in the Outliner, that indicates
if an item is inserted before, after or into. There is some work on that but
that can be done separately.
Changes:
- Removes `AbstractViewDropTarget` that was shared between tree- and
grid-views, and adds `AbstractTreeViewDropTarget` and
`AbstractGridViewDropTarget`. The tree-view needs specialized handling now,
and although they could share some code still, it's not worth having another
level of inheritance.
- Modifies the drop-target API to use `DragInfo` which contains more info about
the dragging operation than just the `wmDrag`.
- Adds `determine_drop_location()` to the `DropTargetInterface` which drop
targets can use to determine when dropping means inserting before, after or
into.
- Store the block and region in the view. This is needed unfortunately but
shouldn't be an issue since the tree view is recreated on redraws, together
with the block.
- Various smaller tweaks and additions to views as needed.
TODO (outside scope of this change): Increase row height so there is no gap
between tree view items, but keep things visually the same otherwise. This
reduces flickering while dragging.
Pull Request: https://projects.blender.org/blender/blender/pulls/109825
No user visible changes expected.
This function was added in 86b2cf4574 as a more type safe and more
convenient way of setting button callbacks. So use it for simple cases.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
