Calling this state "active" has been confusing for a long time for a number of reasons:
- It's not clear that this is essentially a mouse hover state.
- Easy to confuse with "select" state (`UI_SELECT`), both terms are vague.
- Buttons can be "inactive" (`UI_BUT_INACTIVE`) which is totally related to this "active" state.
- Button handling can consider a button as active that doesn't have this flag set (e.g. during text input).
- Active and selected are well established terms in Blender, but they mean a different thing there.
See #112160.
Pull Request: https://projects.blender.org/blender/blender/pulls/114113
There was a little hack to remove padding from buttons following the collapse
icon by setting the `UI_BUT_NO_TEXT_PADDING` flag, since that added excessive,
weird looking spacing. This shouldn't be done for buttons with icons, as it
moves the icons too close to the collapse chevron, and is visibly inconsistent
with other icon labels in the tree.
Turns out, that the entire hack to set the `UI_BUT_NO_TEXT_PADDING` flag is
unnecessary since 5c2330203e, which sets the flag everywhere for comparable
situations. So the hack can be removed.
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.
Part of #107742.
There used to be a small margin between items since the layout feels a
bit crammed otherwise. But this meant the mouse could be between items,
with no item highlighted or reacting to interactions. This was
especially annoying when dragging over items for drag and drop: in
between items dropping wasn't possible, and the drag-tooltip would
disappear, causing notable flickering during motions over the tree view.
The view item is now slightly enlarged to keep a look that is not too
crammed, and still remove the space between items. Item highlights are
still drawn with a smaller height (matching the normal widget height),
since anything else looked odd to me.
This now feels quite consistent with similar UIs (e.g. File Browser list
view or the Outliner), even though we give the items a bit more space.
Including <iostream> or similar headers is quite expensive, since it
also pulls in things like <locale> and so on. In many BLI headers,
iostreams are only used to implement some sort of "debug print",
or an operator<< for ostream.
Change some of the commonly used places to instead include <iosfwd>,
which is the standard way of forward-declaring iostreams related
classes, and move the actual debug-print / operator<< implementations
into .cc files.
This is not done for templated classes though (it would be possible
to provide explicit operator<< instantiations somewhere in the
source file, but that would lead to hard-to-figure-out linker error
whenever someone would add a different template type). There, where
possible, I changed from full <iostream> include to only the needed
<ostream> part.
For Span<T>, I just removed print_as_lines since it's not used by
anything. It could be moved into a .cc file using a similar approach
as above if needed.
Doing full blender build changes include counts this way:
- <iostream> 1986 -> 978
- <sstream> 2880 -> 925
It does not affect the total build time much though, mostly because
towards the end of it there's just several CPU cores finishing
compiling OpenVDB related source files.
Pull Request: https://projects.blender.org/blender/blender/pulls/111046
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, except of new experimental feature
option.
------------------------------------------------------------------------------
This introduces asset shelves as a new standard UI element for accessing
assets. Based on the current context (like the active mode and/or tool), they
can provide assets for specific workflows/tasks. As such they are more limited
in functionality than the asset browser, but a lot more efficient for certain
tasks.
The asset shelf is developed as part of the brush assets project (see #101895),
but is also meant to replace the current pose library UI.
Support for asset shelves can quite easily be added to different editor types,
the following commit will add support for the 3D View. If an editor type
supports asset shelves, add-ons can chose to register an asset shelf type for
an editor with just a few lines of Python.
It should be possible to entirely remove `UILayout.asset_view_template()` once
asset shelves are non-experimental.
Some changes are to be expected still, see #107881.
Task: #102879
Brush asset workflow blog post: https://code.blender.org/2022/12/brush-assets-workflow/
Initial technical documentation: https://developer.blender.org/docs/asset_system/user_interface/asset_shelf/
Pull Request: #104831
The `on_activate()` function is expected to do undo pushes, call
operators, send notifiers and things like that as needed. Context is
necessary for such things, so seems reasonable to provide it as
argument.
Also needed for #110378.
Much of this was duplicated between grid view and tree view items which
keeping them in sync was becoming a hassle already. Now the logic is
shared via the base class. I find this makes the interfaces easier to
scan through visually as well.
Had to add a virtual iterator function that can be called on an
`AbstractView`.
The `on_activate()` function of an item should only be called when the
item was activated through the view, not through an external data change
(e.g. changing an active item through Python). That is important because
`on_activate()` is expected to do things like sending an undo push. This
is now respected in tree and grid views.
No user visible changes expected.
Previously the calculations to skip building the layout for invisible
items used the scrolling offsets quite a bit. These values are managed
in code elsewhere, better to minimize such dependencies. Plus we can
rely less on floating point values, making code more simple & reliable.
As an important optimization, grid views skip items that are not in
view, and instead add empty space to the layout still has the right
dimensions (for scrolling). Calculations were off though, leading to the
last row being dropped when it had too few items to fill it completely.
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
Hierarchy lines (like we also have in the Outliner) make it easier to
visually parse the hierarchy, and avoid confusion about nesting level.
Especially when some items have icons and/or collapse chevrons and some
not (thus different levels of visual indentation).
They were planned for #93582 and #107881, also see
https://code.blender.org/2023/05/the-next-big-step-grease-pencil-3-0/#layer-groups.
The drawing is implemented as a general tree-view feature, so all
tree-views with collapsable items (which excludes the spreadsheet
data-set tree view) will get them without further setup.
No user visible changes expected.
Adds an assert to check that only one item returns true in its
`should_be_active()` method. This can help find some errors.
No user visible change expected (this isn't used in existing code yet).
Users of the tree-view API should be able to write their own `matches()`
method to compare tree-view elements after tree reconstruction. Part of
the tree-view matching process wouldn't use this though, and use the
`matches_single()` method instead, causing issues like multiple items
sharing the same state. This was initially done for an optimization
(the default `matches()` compares parents as well, which seems redundant
here), but it backfires and actually isn't needed. The default
`matches()` only compares the parents when `matches_single()` returns
true anyway, so the redundancy is really minor and not a performance
concern.
No user visible changes expected.
It makes sense to disable embossing for drawing the tree view (so it
doesn't have to be disabled for every item individually), but then the
mouse hover highlight should still work.
No user visible changes expected.
In some cases you'd want a view in which no, or not all items can be
activated. Needed for #104831, but makes sense as a general feature for
UI view items.
No user visible changes expected.
Needed for the asset shelf (#102879).
Adds a UI operator triggered on Ctrl+F that will attempt to start
filtering for the hovered UI view, typically enabling a filter text
button.
View items can implement their own filter method, there's no default
one. Maybe we should add default or re-usable string filtering method
though.
Filtering is applied after constructing the view and filtered out (as
in, invisible) items are kept in storage, so that their state
(selection, active, etc.) is preserved. The filtered state is cached in
the item, so this is only done once per redraw.
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/
No user visible changes expected (since grid-views are only used in
branches right now).
This just makes grid view UIs feel more "stable" while scaling areas,
since things don't move around as much anymore. The tradeoff is that
there may be some empty space on the right, if there's not enough space
for a full column. This is how the file browser already behaves, and can
be mitigated by a smaller preview size.
The highlighting of preview tiles would be too strong in asset view
templates and grid views (only used in branches so far). This is because
two buttons are overlayed on top of each other, and both would
highlight. Ensure the overlayed preview tile button doesn't use any
highlighting.
For example
```
OIIOOutputDriver::~OIIOOutputDriver()
{
}
```
becomes
```
OIIOOutputDriver::~OIIOOutputDriver() {}
```
Saves quite some vertical space, which is especially handy for
constructors.
Pull Request: https://projects.blender.org/blender/blender/pulls/105594
No user visible changes expected.
With this, empty rows will be added to the tree view so that the
background box is at least a few lines high (like with UI lists). If the
view is used as a drop target, data can be dropped on these empty rows
too then.
This was requested for the Cycles light linking project.
These often want to store a non-const reference to its owner, i.e. the
object that created them. I don't really like removing const here, but
it makes sense to enable this use case.
Previously UI view items would support custom drop controllers (so they
could react to data being dragged over them and dropped). This is now
more generalized so the views themselves can do this as well.
Main changes:
- Support calculating a bounding box for the view, so this can be used
for recognizing mouse hovering.
- Rename "drop controller" to "drop target", this is more clear, less
abstract naming.
- Generalize drop controllers/targets. There is a new
`ui::DropTargetInterface` now.
- Add support for drop targets in the `ui::AbstractView` base class, so
custom views can use this.
Pull Request: https://projects.blender.org/blender/blender/pulls/105963
The Cycles light linking branch is using the tree view UI but it seemed
to use the "wrong" layout. It wasn't clear that the layout has to be
reactivated before building the view.
Make it harder to use the API wrong now by requiring the layout as
argument, so the building can ensure it's active.
No user-visible changes expected.
Essentially, this makes it possible to use C++ types like `std::function`
inside `uiBut`. This has plenty of benefits, for example this should help
significantly reducing unsafe `void *` use (since a `std::function` can hold
arbitrary data while preserving types).
----
I wanted to use a non-trivially-constructible C++ type (`std::function`) inside
`uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore.
Rather than writing worse code, allow non-trivial construction for `uiBut`.
Member-initializing all members is annoying since there are so many, but rather
safe than sorry. As we use more C++ types (e.g. convert callbacks to use
`std::function`), this should become less since they initialize properly on
default construction.
Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate
based on size isn't working anymore.
Differential Revision: https://developer.blender.org/D17164
Reviewed by: Hans Goudey
This is the conventional way of dealing with unused arguments in C++,
since it works on all compilers.
Regex find and replace: `UNUSED\((\w+)\)` -> `/*$1*/`
