The main simplification is using return values rather than return
arguments, and the additional semantic clarity from std::optional.
Also use `fmt` for formatting and use lambdas instead of macros
as helpers in a few modal keymap formatting functions.
Similar commits:
- a1792e98a4
- f04bc75f8c
- 6abf43cef5
- 7ca4dcac5a
Pull Request: https://projects.blender.org/blender/blender/pulls/117785
The benefits are O(1) access to the string size, clearer ownership,
and easily accessible utility functions. For now, only change functions
where the string is clearly non-null. It's not clear in what cases some
other functions recieve null strings.
As discussed in the UI Module Meeting we don't have an acceptable use
case for dialogs that use the Blender logo. Removing this image from
the project since this is now exposed through dialog customization.
Pull Request: https://projects.blender.org/blender/blender/pulls/117676
When a string shouldn't be used or is invalid, use std::nullopt to
make it clear it's value shouldn't be used.
Without this it's possible to accidentally use an empty string
which will silently fail.
For some reason the "get" function actually allocates the button's
operator properties container. This may or may not make sense to
do, but while it happens, the function name might as well make
that clear.
Caused by 089c389b5c. Previously the draw string was created
by appending text inside the buffer multiple times. Now it's formatted
in one step. Part of that change was missing for factor display.
Instead of a single function with variadic arguments, a special enum
type containing which string to request, and a special struct to
contain the request and the result, just use separate functions for
each request, and return a std::string by value. Also change the enum
item string access to just give access to the enum item itself and add
const in a few places as necessary.
The callers of the API function get much clearer this way, and it's
much easier to see which information is used to create certain tooltip
strings.
Caused by 29f3af9527, exposed by bff51ae66c.
The problem was that a `uiBut` pointer was being passed to a function
and then dereferenced as a `PanelType`. In the past, the button used to
just have zeros where the pointer was then read from, but after the
changes in the second commit, this was no longer the case.
Fix by being more explicit about the argument type, and changing the
argument from a button to the panel type for one callback. It's a bit
complex because the panel type and panel type idname are stored in
different places depending on the button type.
Change the behavior of UI_but_string_info_get to fill in shortcuts
when requested.
Previously shortcuts were ignored for menus, because showing shortcuts
in tool-tips which are already displayed in the menu isn't needed.
Move this logic to tool-tip creation so other the shortcuts may be
accessed in other contexts.
The previous commit introduced a new `RPT_()` macro to translate
strings which are not tooltips or regular interface elements, but
longer reports or statuses.
This commit uses the new macro to translate many strings all over the
UI.
Most of it is a simple replace from `TIP_()` or `IFACE_()` to
`RPT_()`, but there are some additional changes:
- A few translations inside `BKE_report()` are removed altogether
because they are already handled by the translation system.
- Messages inside `UI_but_disable()` are no longer translated
manually, but they are handled by a new regex in the translation
system.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
This adds support for so called "layout panels" which are panels that are created as part
of `uiLayout`. The goal is to make it easier to have expandable sections as part of a UI.
The initial use case for this are panels in the geometry nodes modifier. This patch provides
a better solution compared to what was attempted in #108565.
### Problems with Existing Approaches
Currently, there are two ways to create these expandable sections:
* One can define a new `Panel` type for each expandable section and use the `parent_id`
to make this a subpanel of another panel. This has a few problems:
* `uiLayout` drawing code is more scattered, because one can't just use a single function
that creates the layout for an entire panel including its subpanels.
* It does not work so well for dynamic amounts of panels (e.g. like what we need for
the geometry nodes modifier to organize the inputs).
* Typically, Blender uses a immediate-ui approach, but subpanels break that currently
and need extra handling.
* The order of panels is not very explicit.
* One can't interleave subpanels and other ui elements, subpanels always come at the
end of the parent panel.
* Custom solution using existing `uiLayout`. This is done in the material properties. It
also has a few problems:
* Custom solutions tend to work slightly different in different places. So the UI is less unified.
* Can't drag open/close multiple panels.
* The background color for subpanels does not change.
### Solution
A possible solution to all of these problems is to add support for panels to `uiLayout` directly:
```cpp
/* Add elements before subpanel. */
if (uiLayout *panel_layout = uiLayoutPanel(layout, ...)) {
/* Add elements in subpanel, but only of the panel is open. */
}
/* Add elements after subpanel. */
```
Integrating subpanels with `uiLayout` has some benefits:
* Subpanels are treated like any other sub-layout and don't have unnecessary boilerplate.
* It becomes trivial to have a dynamic number of potentially nested subpanels.
* Resolves all mentioned problems of custom subpanel solutions.
### Open/Close State
The most tricky thing is to decide where to store the open/close state. Ideally, it should
be stored in the `region` because then the same layout panel can be opened and closed
in every region independently. Unfortunately, storing the state in the region is fairly
complex in some cases.
For example, for modifier subpanels the region would have to store an open/close state
for each panel in each modifier in each object. So a map with
`object pointer + modifier id + panel id` as key would be required. Obviously, this map
could become quite big. Also storing that many ID pointers in UI data is not great and
we don't even have stable modifier ids yet. There also isn't an obvious way for how to
clear unused elements from the map which could become necessary when it becomes big.
In practice, it's rare that the same modifier list is shown in two editors. So the benefit of
storing the open/close state in the region is negligible. Therefor, a much simpler solution
is possible: the open/close state can be stored in the modifier directly. This is actually
how it was implemented before already (see `ui_expand_flag`).
The implementation of layout panels in this patch is *agnostic* to how the open/close
state is stored exactly, as long as it can be referenced as a boolean rna property. This
allows us to store the state in the modifier directly but also allows us to store the state
in the region for other layout panels in the future. We could consider adding an API that
makes it easy to store the state in the region for cases where the key is simpler.
For example: `uiLayoutPanel(layout, TIP_("Mesh Settings"), PanelRegionKey("mesh_settings"))`.
### Python API (not included)
Adding a Python API is fairly straight forward. However, it is **not** included in this patch
so that we can mature the internal API a bit more if necessary, before addon developers
start to depend on it. It would probably work like so:
```python
if panel := layout.panel("Mesh Settings", ...):
# Add layout elements in the panel if it's open.
```
Pull Request: https://projects.blender.org/blender/blender/pulls/113584
NDEBUG is part of the C standard and disables asserts. Only this will
now be used to decide if asserts are enabled.
DEBUG was a Blender specific define, that has now been removed.
_DEBUG is a Visual Studio define for builds in Debug configuration.
Blender defines this for all platforms. This is still used in a few
places in the draw code, and in external libraries Bullet and Mantaflow.
Pull Request: https://projects.blender.org/blender/blender/pulls/115774
Report #115815 shows a time where our calculation of rows and columns
should also include the category name lines. The code was calculating
where to break not including these and is too short if it has a
category.
Pull Request: https://projects.blender.org/blender/blender/pulls/115822
- Support passing in unterminated C-strings when clamped by the size
argument.
- Pair string and it's size arguments together in IDP_NewStringMaxSize.
- Remove redundant size check which made it seem as if the string
might not be null terminated.
- Replace clamping the result of strlen(..) with BLI_strnlen,
to avoid calculating the length past the size checked.
- Add doc-string for unclamped string creation.
Makes it possible to swipe over panel header to batch open/collapse all
panels the mouse draged over. Normal panels and sub-panels support this
too.
Two changes were needed:
- Support "drag toggle" feature for `UI_BTYPE_BUT_TOGGLE` - all toggle
buttons should/can support this.
- Allow querying the pushed state from the button used for the
collapsing. Multiple ways to do this, in this case simply using the
pushed state query callback seemed simplest.
Pull Request: https://projects.blender.org/blender/blender/pulls/114560
Makes it possible to swipe over the checkboxes used to enable or disable
catalogs in the asset catalog selector popup, to batch enable or disable
the ones dragged over.
Might also enable this feature for other cases where checkboxes are
displayed.
