Code to check if the Outliner tree-element type was the general ID one
would always check against "0" (explicity or even implicitly). For
somebody unfamiliar with the code this is very confusing. Instead the
value should be given a name, e.g. through an enum.
Adds `TSE_SOME_ID` as the "default" ID tree-element type. Other types
may still represent IDs, as I explained in a comment at the definition.
There may also still be cases where the type is checked against "0". I
noted in the comment that such cases should be cleaned up if found.
In Blender, we used to use the term 'draw' to refer to information
displayed to the user. For version 2.80, it was decided to change these
instances to 'display' instead. This was to avoid the ambiguity between
end-user drawing tools and display options.
From the Oxford English Dictionary:
- Draw: produce (a picture or diagram) by making lines and marks on
paper with a pencil, pen, etc.
- Display: show (data or an image) on a computer, television, or
other screen.
Therefore, we should use draw when referring to drawing tools for
making marks, but use display when referring to information
shown/displayed to the user. From a user POV, the computer displays
certain information, whereas the user draws a mark.
Apparently this change was not implemented consistently, so this patch
changes all remaining relevant instances of "draw".
Differential Revision: https://developer.blender.org/D10551
This concerns currently only collections (`master_collection` of scenes)
and root node trees. It removes the matching type-specific helpers
(`BKE_collection_master_scene_search` and `BKE_node_tree_find_owner_ID`).
No functional change expected here.
NOTE: Current implementation of `owner_get` is far from optimal, we
could probably do it better, see {T69169}.
NOTE: While it could also have it, shapekeys IDTypeInfo was left out of
this change for now. Mainly because it sould not be used currently, and
we ultimately want to demote shape keys from ID status anyway.
Most collection operations should not be allowed when either the scene
or the parent collection are linked or liboverrides.
This commit adds more stricter checks in both polling and execution
aspects of several related operators.
Fix T81282: Crash on instance to scene of a collection of a linked scene.
That project cannot be opened correctly ayway, it has recursive
collections intanciating themselves...
But at least now we have a check at startup to detect and 'fix' those
nasty cycles in collections.
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/editors/space_outliner` module.
No functional changes.
Main change from user side, besides that all pointers should now be
properly remapped to new IDs, is that linked objects are no longer
preserved when doing a full copy of scenes.
Will open a task to check whether we actually still want that behavior
(and re-code it in a more correct way then).
This is the main part of work done here, it aims at uniformizing and
sanitizing that 'deep copy' process for supported IDs (currently scenes,
collections and objects).
Note that there will be more follow up commits after that one, but this
should be the most risky and changing one.
It makes no sense to deep-copy a collection and not also copy its
children collections... Parameter was not used anymore anyway.
So now this duplicate function will always at least deep-duplicate all
of its children collections, recursively.
In the industry standard keymap, both deleting objects and collections
were mapped to the same keys causing confusion when only collections
could be deleted through the keymap.
This adds a new delete operator to delete all selected objects and
collections, accessible from both the keymap and context menu. Now any
selected objects and collections are deleted when Delete is chosen from
the keymap. This also updates the tooltip description which was
previously undocumented.
Resolves T67462
A few outliner operators that modify selection were not tagging for a
selection sync which led to selection inconsistencies. This adds syncing
for the following operators:
* Duplicating and deleting collections
* Selecting/deselecting collection contents
* Drag and drop
* Object select, deselect, delete, and delete hierarchy
Excluding a collection also changes the exclude setting on all child collections
so that it is possible to selectively enable some children without the parent
being enabled.
This change makes it so that if you unexclude the parent, the exclude setting
of children are restored again instead of being permanently lost.
Original patch by Szymon with modifications by Brecht.
Differential Revision: https://developer.blender.org/D7016
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
This allows deleting both collections and objects in the outliner
selection at the same time. This only works using the keyboard shortcuts
(X or Delete).
While this works, a more robust solution should be implemented later to
allow deleting the whole selection from the context menu as well.
The old convention was easy to confuse with ScrArea.
Part of https://developer.blender.org/T74432.
This is mostly a batch rename with some manual fixing. Only single word
variable names are changed, no prefixed/suffixed names.
Brecht van Lommel and Campbell Barton both gave me a green light for
this convention change.
Also ran clan clang format on affected files.
Users now can turn on in a viewport collections that are temporarily
hidden (eye) in the view layer.
Design task: T61327
As for the implementation, I had to decouple the visibility in the
depsgraph from the visibility in the view layer.
Also there is a "bug" that in a way was there before which is some
operators (e.g., writing a text inside of a text object, tab into edit
mode) run regardless of the visibility of the active object. The bug was
present already (with object type visibility restriction) in 2.80 so if
we decide to tackle it, can be done separately (I have a patch for it
though P1132).
Reviewed by: brecht (thank you)
Differential Revision: D5992
How to reproduce: use 1-10 to change the visible collection. If the
collection was globally invisible, it would be set to globally visible.
This was a left over from the previous collection visibility design.
Now that we have a more clear separation between temporary visibility
(i.e., layer collection visibiilty) and a global visibility setting
(i.e., collection visibility) we should keep them separated.
Bringing the same logic we do in the outliner restrict column callback
and the menu call.
Also removing the "change depsgraph" logic there. Isolate collections
should not affect depsgraph relations (if it does it is to be tackled
separately anyways).
No major API change here, only in the outliner restriction column
variables (e.g., show_restrict_column_selectable > show_restrict_column_select).
* Get rid of _INSTANCE (introduced on b1af682001).
* Differentiate (everywhere but the API) between HIDE (temporary) and VIEWPORT (global).
* Use the expected icon for restrict viewport (same as objects and modifiers).
* selectable > select
- Fix 'ddisable' typo
- Use clearer names for the operators in the Collections context menu
Instead of Set Exclude / Clear Exclude, we now use Enable in View Layer / Disable from View Layer
See T61578 for discussions and mockups.
Visibility Options
==================
We are adding more granular control over restriction columns in the outliner,
exposing "indirect only" and "holdout" as options, and change the way
users enable/disable collections in a viewlayer.
We also rename the object viewport restriction to hide instance.
So the options we have are:
Collection
----------
* Render Visibility
* Instance Visibility
* Selectable
(View) Layer Collection
-----------------------
* Enable
* Holdout
* Indirect Only
* Viewport
Shortcuts
=========
Isolate Collection
------------------
* Ctr + click isolates the collection.
It turns all its parents and children "visible", and all the other
collections "invisible".
If ALL the collections were already properly set, we re-set the
collections to their default value.
Set Collection Inside Collections and Objects
---------------------------------------------
* Shift + click: Set/unset inside collections and objects.
We only set objects values as well when we are in View Layer mode and
(obviously) when the objects have a matching property.
Icons
=====
Little reminder that we will need better icons for holdout, indirect only, and
probably instanced (nothing wrong with the current, but it differs from
the proposal when it is turned off).
Also, we need to decide where do we want the modifier/bones/... icons to
be (in which column) and ideally make sure their icons match the ones we
use for collections/objects.
At the moment those are using the screen icon, which is not being used
by collections.
Reviewers: brecht, billrey
Subscribers: pablovazquez
Differential Revision: https://developer.blender.org/D4823
In other words, Duplicate Collection could link local ID into a linked
one... Nasty. ;)
Add checks that found parent is not a linked data-block (and try to
find a fall-back one if this is the case).
This partially reverts commit a77feabb51,
removing the shallow 'duplicate hierarchy' option from outliner.
Core changes from that commit in BKE_collections are kept.
Convention was not to but after discussion on 918941483f we agree its
best to change the convention.
Names now mostly follow RNA.
Some exceptions:
- Use 'nodetrees' instead of 'nodegroups'
since the struct is called NodeTree.
- Use 'gpencils' instead of 'grease_pencil'
since 'gpencil' is a common abbreviation in the C code.
Other exceptions:
- Leave 'wm' as it's a list of one.
- Leave 'ipo' as is for versioning.
Point is, you may want to duplicate your set of collections, but not
duplicate all their objects.
Some notes:
* Am rather skeptical about the practice of using operator name to
define behavior of some common exec code. Imho, that should be a single
operator with an enum to refine its behavior (@cambpellbarton may also
have an opinion here?). Left it as-is for now, because this seems to be
used by other operators too in that code. :/
* @dfelinto, @pablovazquez, @billreynish am not so happy with current
names, but cannot find really good short ones either... Also, shouldn't
we move those into a dedicated `Duplicate` sub-menu?
Now that we have better options (duplicate collection and duplicate linked) there is no
longer need for the original dupli operator.
In fact, as it was it was of little use if you ever had nested collections.
As per the suggestion on T57064, this introduces two new options to duplicate collections.
We then have:
* Duplicate > Collection (New collection with linked content).
* Duplicate > Hierachy (Duplicate entire hierarchy and make all contents single user).
* Duplicate > Linked Hierarchy (Duplicate entire hierarchy keeping content linked with original).
Development TODO: `single_object_users` can/should use the new functions.
Reviewers: brecht, mont29
Subscribers: pablovazquez, billreynish, JulienKaspar
Differential Revision: https://developer.blender.org/D4394
