When duplicating a layer collection directly linked to the view layer we copy
the collection and link it.
For all the not directly linked layer collectionns, we try to sync the layer
collection flags, overrides, ...
Also we make sure the new collection is right after the original collection.
We also expose this in RNA, via collection.duplicate().
This was introduced to the outliner when we had no User Preference
window back in 2.5x. Right now it makes no sense to keep this around.
But how about addon user preferences:
* They belong in the user preference window under the addon.
How about the user preferences themselves:
* You find them in the user preference window.
And templates?
* Why are they here in the first place?
After talking to Pablo Vazquez (who in turn poked Sergey Sharybin) we found
it reasonable to get rid of this. If it turns out that we were wrong we
revert this.
As for leaving this exposed as a debug option (as suggested on IRC) I would say
no, please. This end up polluting the code and never cleaned up in the end.
(this was specific talking about templates).
Technical note: I left the functions in outliner still hanging around.
While I used UNUSED_FUNCTION for one of them, for the other one I had to use:
`#if 0` because the function was calling itself, which would fail to build if
I used UNUSED_FUNCTION.
User notes:
The outliner so far was a great system to handle the object oriented workflow
we had in Blender prior to 2.8. However with the introduction of collections
the bloated ammount of data we were exposed at a given time was eventually
getting on the way of fully utilizing the outliner to manage collections and
their objects.
We hope that with this filtering system the user can put together the outliner
with whichever options he or she seem fit for a given task.
Features:
* Collection filter: In case users are only focused on objects.
* Object filter: Allow users to focus on collections only.
* (Object) content filter: Modifiers, mesh, contrainst, materials, ...
* (Object) children filter: Hide object children [1].
* Object State (visible, active, selected).
* Compact header: hide search options under a search toggle.
* Preserve scrolling position before/after filtering [2].
[1] - Note we still need to be able to tell if a children of an object is in a
collection, or if the parent object is the only one in the collection.
This in fact was one of the first motivations for this patch. But it is to
be addressed separately now that we can at least hide children away.
[2] - We look at the top-most collection in the outliner, and try to find it again
after the filtering and make sure it is in the same position as before.
This works nice now. But to work REALLY, REALLY nice we need to also store
the previous filter options to be sure the element we try to keep on top
was valid for both old and new filters. I would rather do this later though
since this smell a lot like feature creeping ;)
Remove no longer needed display options:
* Current Scene (replaced by View Layer/Collections)
* Visible (replaced by filter)
* Selected (same)
* Active (same)
* Same Type (same-ish)
How about All Scenes? I have a patch that will come next to replace the current
behaviour and focus only on compositing. So basically stop showing the objects
and show only view layers, their passes and collections, besides freestyle.
Also, while at this I'm also reorganizing the menu to keep View Layer and
Collections on top.
Developer notes:
* Unlike the per-object filtering, for collections we need to filter at tree
creation time, to prevent duplication of objects in the outliner.
Acknowledgements:
Thanks Pablo Vazquez for helping testing, thinking some design questions
together and pushing this to its final polished state as you see here.
Thanks Sergey Sharybin and Julian Eisel for code review. Julian couldn't do a
final review pass after I addressed his concerns. So blame is on me for any
issue I may be introducing here. Sergey was the author of the "preserve
scrolling position" idea. I'm happy with how it is working, thank you.
Reviewers: sergey, Severin, venomgfx
Subscribers: lichtwerk, duarteframos
Differential Revision: https://developer.blender.org/D2992
This operator not only links a collection, but it creates a new one and then it
links it. Although the preferrable method for users to handle their collections
is when viewing the "Collections", let's explore this workflow for now.
Suggested by Pablo Vazquez, thank you.
Headers should not have operators as much as possible. The exception here is
for datablocks mode when you want to see the active keyset.
Edit menus on the other hand should be clearly distinct from the RMB context
menus. Edit menu options should be only the ones that apply to the entire
outliner, regardless of the selected element.
Context (rmb) menus should be related to the element you RMB on to invoke the
menu. I'm also taking this opportunity to start bringing the context menus
to Python. There is little reason not to, and it helps editing them (In this
case I'm doing it only for the Scene Collection one).
Although this wasn't so obvious since it
only showed up for factory settings and in the preferences window.
Panel display order depends on registration order,
Sorry for the noise. On the bright side we no longer need to move
classes around to re-arrange panels.
There were some issues with how we store outliner tree elements:
Apparently the only removable elements have been data-blocks so far.
When recreating the TreeElements, their TreeStoreElem instances were
mainly identified by their ID pointer. However non-data-blocks mostly
depend on an index. For collections, such an index isn't a reliable
measure though if we want to allow removing items. Depending on it for
identifying the TreeStoreElem instance would cause some quite noticeable
glitches (wrong highlights, two elements sharing highlight, etc).
For now I've solved that by actually removing the TreeStoreElem that
represents the removed element. A little limitation of this is that
after undoing the removal, some information might get lost, like
flags to store selection, or opened/closed state.
A better solution that would also fix this issue would be having a real
unique identifier for each non-data-block element, like an idname or even
its data-pointer. Not sure if we can get those to work reliable with
file read/write though, would have to investigate...
Also added a general Outliner tree traversal utility.
This reverts commit 3da834e83ce9d7056c033148dab04885a6d3b1b7.
We will use the outliner for this now.
I'm also moving the collections_ops.c to outliner_collections.c
Many users have been requesting a way to remove unused datablocks from the file/session
"without closing and reopening" Blender (or at least that's the impression I'm getting).
This commit adds a new operator (exposed as the "Purge All" button in the header of
the "Orphaned Datablocks" mode in the Outliner, which seems to be the logical
place for this) for doing so. It does so by wrapping up the save and "revert"
(i.e. reload the saved file from disk, without needing to quit Blender) operators
along with a confirmation prompt for good measure.
Caveats:
* Ultimately, we still cannot really cleanly delete any datablocks from the current
session outright without reloading the file/data at some point. Thus, we do need
to reload the file again before it can be used.
* This does mean that this operation is irreversible. Notably, Undo history is lost
is doing this operation. Hence the warnings... (Then again, undo/redo actually
reloads the entire scene DB from memory, so it's not anything uncommon ;)
Other Notes:
* The addition of this operator brings this mode more into line with being a kind of
"Trashcan" place, with this new operator being the manual "Empty Trash" button.
If the "Orphaned Datablocks" name is too obscure, maybe we could rename this
mode to "Trash" or something similar?
Organize Maximize/Fullscreen mess and add a new fullscreen mode with no UI
* Maximize Editor: (old Ctrl+Up)
* Full Screen Window: (old Alt + F11)
* Full Screen Editor: new operator (Alt + F10)
* Change Show/Hide Header: (Alt + F9)
When the mode is on moving the mouse near the top right corner of the
editor shows an icon to go back to the normal editor mode.
This was originally intended for the multiview branch, but this
functionality also benefits non-stereo workflows, thus it can be
reviewed and committed independently.
Development notes:
* This includes cleanups in the code to sanitize the naming of
fullscreen/maximize across the window/editor code.
* Originally the idea was to make the window fullscreen as well, but
this idea was dropped.
* You can see the clicking area when debug is 1
* Technically the user can be left with an unfaded icon in the corner
(specially when using a tablet). If we think this is too bad we can
increase the action zone to be the whole screen, or something similar.
Reviewers: campbellbarton [1], ton [2], fsiddi [2]
[1] actual code review
[2] design review
Differential Revision: https://developer.blender.org/D678
Notes:
* Made those edits by full checking of py files, so I should have spoted most needed edits, yet it remains quite probable I missed a few ones, we'll fix if/when someone notice it...
* Also made some cleanup "on the road"!
* Code cleanup in the space_*.py files.
* Removed layout.column() statement in _MT_ panels, they are useless.
* Only define variables at the beginning of a function!
ui/ --> startup/bl_ui
op/ --> startup/bl_operators
scripts/startup/ is now the only auto-loading script dir which gives some speedup for blender loading too.
~/.blender/2.56/scripts/startup works for auto-loading scripts too.
