This adds an optional uiBut callback that allows creating a tooltip
line-by-line with specified style and color in any order. It also
allows adding images as well to create very informative tooltips.
Pull Request: https://projects.blender.org/blender/blender/pulls/105905
The basic idea is very simple. Whenever a supported menu is open, one can just
start typing and this opens a search that contains all the (nested) menu entries.
The main downside is that this collides with accelerator keys. Those are the
underlined characters in each menu. For now, we just enable this new searching
behavior in a few selected menus: Node Add Menu, View3D Add Menu and
Modifier Add Menu.
This new functionality can be enabled for a menu by setting
`bl_options = {'SEARCH_ON_KEY_PRESS'}` to true in the menu type.
The status bar shows `Type to search...` when a menu is opened that supports search.
Pull Request: https://projects.blender.org/blender/blender/pulls/110855
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
Generally the context store is owned by `uiBlock`. Other pointers
to the store (in `bContext` and other operator data) shouldn't change
it, so those variables are now const. One exception is the pointer in
`uiLayout`, but that has a clearly short lifetime, so that's okay.
Some code attempted to use `BIFIconID` instead of `int` to pass around
icon-ids. Problem is, that this is just a subset of the allowed ids,
more icons may be created at runtime and extend the range of valid
icon-ids. Such icons could give runtime warning prints.
Idea is to use a `using BIFIconID = int;` instead. This way there is
still a descriptive type name, while the whole dynamic range of possible
icon-ids is supported.
Additionally multiple `using BIFIconID = int;` declarations are valid,
so we can place these in multiple headers and use the type name in APIs
instead of just `int`, whithout having to include a single header
defining them. A type mismatch (one instance differs from the others)
will result in a compiler error.
Pull Request: https://projects.blender.org/blender/blender/pulls/111052
With the end goal of simplifying ownership and memory management,
and allowing the use of `get_name` in contexts without statically
allocated strings, use `std::string` for the return values of these two
operator type callbacks instead of `const char *` and `char *`.
In the meantime things get uglier in some places. I'd expect `std::string`
to be used more in the future elsewhere in Blender though.
Pull Request: https://projects.blender.org/blender/blender/pulls/110823
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
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
No user visible changes expected. Used in the asset shelf branch,
see #104831.
These tooltips only show a label string and appear after a shorter timeout
than the regular tooltips. After the regular tooltip timeout they expand to
the full tooltip. The toolbar and properties editor navigation tabs make use
of this already.
The changes here enable more control over quick label tooltips, making them
usable in more cases, and less ad-hoc. Main changes:
- Refactors internal logic so a single `UI_BUT_HAS_TOOLTIP_LABEL` button flag
can be used to enable quick label tooltips. This decentralizes logic in a
way that's more consistent and extensible.
- Custom callback to return a quick label. This is useful when a label tooltip
should be displayed even when there is no button string set. E.g. in the
asset shelf with "Show Names" disabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/110200
Avoid potential problems when the active window is known but not
assigned to `wm->winactive`, where the first window would be used
as a fallback. Instead, take a window argument, a fallback is still
used as a last resort (when NULL).
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.
Rather than relying on a C-style function pointer with void pointer
arguments, allow storing a `std::function` object, which can hold
arbitrary data in a type safe way. This can be conveniently used with
lambdas for example.
This is not used yet, but will be with #104831 merged. Replacing the
existing C-style callback uses with this can be done separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/109016
This reverts commit 8ed65fe6de.
Fix#108553: Alt + value change doesn't work for various inputs
Fix#108621: Driven values are no longer marked in purple
C-style callbacks often rely on `void` pointer arguments that are unsafe
because of the removed type. C++ functors allow passing arbitrary data
along the callback, plus convenient features like defining the callback
using a lambda.
Didn't port the `typedef` because it doesn't add much in this case, just
hides the type from the reader who has to look it up first.
Note that this function isn't used in the main branch currently.
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/
Only use the term len & maxlen when they represent the length & maximum
length of a string. Instead of the available bytes to use.
Also include the data they're referencing as a suffix, otherwise it's
not always clear what the length is in reference to.
The length passed to IDP_NewString included the nil terminator
unlike IDP_AssignString. Callers to IDP_AssignString from MOD_nodes.cc
passed in an invalid size for e.g. There where also callers passing in
the strlen(..) of the value unnecessarily.
Resolve with the following changes:
- Add `*MaxSize()` versions of IDP_AssignString & IDP_NewString which
take a size argument.
- Remove the size argument from the existing functions as most callers
don't need to clamp the length of the string, avoid calculating &
passing in length values when they're unnecessary.
- When clamping the size is needed, both functions now include the nil
byte in the size since this is the convention for BLI_string and other
BLI API's dealing with nil terminated strings,
it avoids having to pass in `sizeof(value) - 1`.
Initial idea was to calculate the view boundaries when finishing the
`uiBlock`, after layout code and such ran. But the panel code applies an
offset later, which breaks this. The view boundaries would be off by
something like 100px.
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
