Part of T98560.
See https://wiki.blender.org/wiki/Source/Interface/Views
Adds all the basic functionality needed for grid views. They display
items in a grid of rows and columns, typically with a preview image and
a label underneath. Think of the main region in the Asset Browser.
Current features:
- Active item
- Notifier listening (also added this to the tree view)
- Performance: Skip adding buttons that are not scrolled into view
(solves performance problems for big asset libraries, for example).
- Custom item size
- Preview items (items that draw a preview with a label underneath)
- Margins between items scale so the entire region width is filled with
column, rather than leaving a big empty block at the right if there's
not enough space for another column (like the File and current Asset
Browser does it).
- "Data-View Item" theme colors. Not shown in the UI yet.
No user visible changes expected since the grid views aren't used for
anything yet.
This was developed as part of a rewrite of the Asset Browser UI
(`asset-browser-grid-view` branch), see T95653. There's no reason to
keep this part in a branch, continuing development in master makes
things easier.
Grid and tree views have a lot of very similar code, so I'm planning to
unify them to a degree. I kept things separate for the start to first
find out how much and what exactly makes sense to override.
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
* Correct URL for documentation (was changed recently).
* Add comments.
* Reevaluate and update which functions are public, protected or
private.
* Reorder functions and classes to be more logical and readable.
* Add helper class for the public item API so individual functions it
uses can be made protected/private (the helper class is a friend).
Also allows splitting API implementation from the C-API.
* Move internal layout builder helper class to the source file, out of
the header.
* More consistent naming.
* Add alias for item-container, so it's more clear how it can be used.
* Use const.
* Remove unnecessary forward declaration.
This actually gives a quite nice behavior in my opinion, especially for
asset catalogs, where activating a catalog makes all assets inside it or
its (grand-)child catalogs visible, so showing the child catalogs then
adds useful information. Maybe this should become a feature for
asset catalogs only, to be evaluated once the tree-view API is used in
more cases. Only asset catalogs are affected by this change right now.
Part of T93582.
Assigning a catalog to an asset via drag-and-drop in the asset browser
now creates an undo step. Not only does this allow undoing the action,
it also tags the blend file as modified.
Reviewed by: Severin
Differential Revision: https://developer.blender.org/D13370
Without this it's easy to loose track of which catalog you are dragging.
Things feel generally quite jumpy/disconnected, activating the catalog
makes things feel far less like that.
I consider this an important usability fix, therefore I'm adding it to
the release branch.
It seems that update_from_old assumed there would be an old
tree view available in the old block. This works for the asset browser
because the tree is always drawn, but for the spreadsheet that depends
on having an active object, which isn't necessarily always true.
Differential Revision: https://developer.blender.org/D13301
This patch removes a bunch of specific code for drawing the spreadsheet
data set region, which was an overly specific solution for a generic UI.
Nowadays, the UI tree view API used for asset browser catalogs is a much
better way to implement this behavior.
To make this possible, the tree view API is extended in a few ways.
Collapsibility can now be turned off, and whether an item should
be active is moved to a separate virtual function.
The only visual change is that the items are now drawn in a box,
just like the asset catalog.
Differential Revision: https://developer.blender.org/D13198
This isn't a problem in 3.0 or master, but I'm porting the spreadsheet
data set region to a tree view and ran into this. This line needs to
whether the function is empty before calling it.
Differential Revision: https://developer.blender.org/D13197
This reverts commit 487faed6d0.
I changed my mind on how to implement this feature. Adding a catalog
should also activate it, like we do it for adding other data in Blender.
The activation will automatically make it visible then. See the
following commit.
When pressing the '+' icon to add a new child catalog, or when adding it
through the context menu, the new catalog should be visible. So the
this change makes sure the parent is uncollapsed if needed.
Adds the needed bits to the UI tree-view API to support dragging
tree-view items. This isn't used yet, but will be in the following
commit for asset catalogs.
There will probably be some further tweaks to the design at some point,
for now this should work well enough for our use-cases.
The label was placed right at the left border of the row highlight,
which looked weird. So add some padding to tree-row labels without icon
or collapse chevron, which makes it look more polished. As additional
benefit, it alignes the labels better with icons of other rows on the
same tree level. And the padding makes it more clear that a child is
indeed a child, not just a sibling without icon.
A tree-view item's drop controller can now return a message for the user
explaining why dropping isn't possible with the dropped data. This is then
displayed in red text next to the cursor.
This isn't actually used yet, the follow up commit will do that.
Introduces a dropping-controller API for the tree-view items,
`AbstractTreeViewItemDropController`. This reduces responsibilities of the main
tree-view item classes, which are already getting quite big. As I expect even
more functionality to be needed for it (e.g. drag support), it's better to
start introducing such controller types already.
This change simplifies the parameter list for these functions
and reduces the chance of typos mixing up array indices.
Reviewed By: campbellbarton
Ref D12950
Use arrays for wmEvent coordinates, this quiets warnings with GCC11.
- `x, y` -> `xy`.
- `prevx, prevy` -> `prev_xy`.
- `prevclickx, prevclicky` -> `prev_click_xy`.
There is still some cleanup such as using `copy_v2_v2_int()`,
this can be done separately.
Reviewed By: campbellbarton, Severin
Ref D12901
Previously, when an item was active and its parent (or grand parent, etc.) was
collapsed, the active item would simply not be visible anymore. It seemed like
there was no active item. So instead, change the just collapsed parent to be
the active item then, so the active item stays visible.
Tree-view items can now easily define their own context menu. This works
by overriding the `ui::AbstractTreeViewItem::build_context_menu()`
function. See the documentation:
https://wiki.blender.org/wiki/Source/Interface/Views#Context_Menus
Consistently with the Outliner and File Browser, the right-clicked item
also gets activated. This makes sure the correct context is set for the
operators and makes it clear to the user which item is operated on.
An operator to rename the active item is also added, which is something
you'd typically want to put in the context menu as well.
Disables undo for:
* The tree row collapsing - which doesn't make sense to undo, isn't
supported by the undo system, and just triggers the confirmation
prompt when closing the file.
* Renaming items - While this may make sense in some cases, users of the
tree-view API can explicitly do an undo push. For asset catalogs it's
not supported.
This reworks how tree rows are constructed in the layout and how they
behave in return.
* To open or collapse a row, the triangle/chevron icon has to be clicked
now. The previous behavior of allowing to do it on the entire row, but
only if the item was active already, was just too unusual and felt
weird.
* Reduce margin between chevron icon and the row label.
* Indent child items without chevron some more, otherwise they feel like
a row on the same level as their parent, just without chevron.
* Fix renaming button taking entire row width. Respect indentation now.
* Fix double-clicking to rename toggling collapsed state on each click.
Some hacks/special-handling was needed so tree-rows always highlight
while the mouse is hovering them, even if the mouse is actually hovering
another button inside the row.
Was just comparing this item's and the parent item's names. But if an item has
no parents, only its own name has to match for the check to return true. Make
sure that the number of parents also matches.
Now the icons to add or delete catalogs are only shown when mouse hovering a
catalog item in the tree. This is convenient for quick creation of catalogs,
and doesn't require activating a catalog to edit it first.
Determining if a tree item is hovered isn't trivial actually. The UI tree-view
code has to find the matching tree-row button in the previous layout to do so,
since the new layout isn't calculated yet.
The UI code to ensure consistent button state over redraws was just comparing
the name of the item, ignoring the parent names. So with multiple items of the
same name, there might have been glitches (didn't see any myself though).
There's a leftover to-do though, we don't check yet if the matched buttons are
actually from the same tree. Added TODO comment.
Catalogs can now be renamed by double clicking them in the Asset
Browser. This is mostly done through the tree-view API, the asset
specific code is very little.
There is some polish left to be done here, e.g. the double click
currently also collapses/uncollapses and activates the clicked item. And
the rename button takes the full width of the row. But addressing these
is better done as part of some other behavioral changes that are planned
anyway.
Makes things look more appealing visually. Plus it's a way to visually
group the tree rows together, which can be important if there are more
widgets surrounding the tree.
Issue was that the `on_activate()` callback of tree-items were
continuously called, because the active-state was queried before we
fully reconstructed the tree and its state from the previous redraw.
Such issues could happen in more places, so I've refactored the API a
bit to reflect the requirements for state queries, and include some
sanity checks.
The actual fix for the issue is to delay the state change until the tree
is fully reconstructed, by letting the tree-items pass a callback to
check if they should be active.
The `ui::BasicTreeViewItem` took a function-like object to execute on
item activation via the constructor. This was mainly intended to be used
with lambdas. However, it's confusing to just have this lambda there,
with no indication of what it's for (activation).
Instead, assign the function-like object via an explicit `on_activate()`
function.
Makes sure that the active item of a tree never has collapsed parent
items, which can be confusing if it happens. E.g. for the asset catalogs
UI, the active catalog decides which assets are visible. Having it
hidden while being the main factor deciding which assets are visible is
quite confusing.
I think it makes sense to have this at the UI Tree-View level, rather
than doing it manually in the asset catalog code for example. Seems like
something you'd commonly want. We can make it optional in the API if
needed.
Renamed the `set_active()` function to make clear that it is more than a
mere setter.
Adds an easy way to add drop support for tree-view rows.
Most of the work is handled by the tree-view UI code. The tree items can
simply override a few functions (`can_drop()`, `on_drop()`,
`drop_tooltip()`) to implement their custom drop behavior.
While dragging over a tree-view item that can be dropped into/onto, the
item can show a custom and dynamic tooltip explaining what's gonna
happen on drop.
This isn't used yet, but will soon be for asset catalogs.
See documentation here:
https://wiki.blender.org/wiki/Source/Interface/Views#Further_Customizations
The Asset Browser now displays a tree with asset catalogs in the left
sidebar.
This replaces the asset categories. It uses the new UI tree-view API
(https://wiki.blender.org/wiki/Source/Interface/Views#Tree-View).
Buttons are displayed for adding and removing of catalogs. Parent items
can be collapsed, but the collapsed/uncollapsed state is not stored in
files yet.
Note that edits to catalogs (e.g. new or removed catalogs) are only
written to the asset library's catalog definition files when saving a
.blend.
In the "Current File" asset library, we try to show asset catalogs from
a parent asset library, or if that fails, from the directory the file is
stored in. See adaf4f56e1.
There are plenty of TODOs and smaller glitches to be fixed still. Plus a
UI polishing pass should be done.
Important missing UI features:
* Dragging assets into catalogs (WIP, close to being ready).
* Renaming catalogs
* Proper handling of catalogs in the "Current File" asset library
(currently not working well).
The "Current File" asset library is especially limited still. Since this
is the only place where you can assign assets to a catalog, this makes
the catalogs very cumbersome in general. To assign an asset to a
catalog, one has to manually copy the Catalog ID (a random hash like
number) to the asset metadata through a temporary UI in the Asset
Browser Sidebar. These limitations should be addressed over the next few
days, they are high priority.
Differential Revision: https://developer.blender.org/D12670
This follows three main targets:
* Make creation of new tree UIs easy.
* Groundwork to generalize tree UIs (so e.g. Outliner, animation
channels, asset catalogs and spreadsheet data-sets don't have to
re-implement basic tree UI code) or even other data-view UIs.
* Better separate data and UI state. E.g. with this, tree-item selection
or the open/collapsed state can be stored on the UI level, rather than
in data. (Asset Catalogs need this, storing UI state info in them is
not an option.)
In addition, the design should be well testable and could even be
exposed to Python.
Note that things will likely change in master still. E.g. the actually
resulting UI isn't very nice visually yet.
The design is documented here:
https://wiki.blender.org/wiki/Source/Interface/Views
Differential Revision: https://developer.blender.org/D12573
