This converts the public `uiItemFullO_ptr` function to an object
oriented API (an `uiLayout::op` overload), matching recents changes
in the API.
Changes include rearranging the `IDProperty *properties` parameter to be
the last parameter. Now is optional (but will be removed), also instead
of using a return parameter the function now returns the pointer to
write properties.
Pull Request: https://projects.blender.org/blender/blender/pulls/139166
The Path Template errors reported in tooltips could be incorrect,
depending on whether the field was visually truncated in the UI or not.
For example, if you had a path `/tmp/{blend_name}{foo`, the error is
that the template expression `{foo` is unclosed. However, if the
available space for the field in the UI is too small, the displayed path
could end up as `/tmp/{blend_na...`. This is for display purposes only,
and shouldn't effect things like template errors. However, it did, and
the error checking would be run on that display string, and report that
`{blend_na...` is unclosed, which is incorrect.
The issue was that the code doing the live error checking for the UI was
using the display string because it was conveniently available.
This fixes the issue by properly querying the property value via RNA,
and using that.
Pull Request: https://projects.blender.org/blender/blender/pulls/139144
This merges the public `uiItemS` and `uiItemS_ex` functions into an
object oriented API (`uiLayout::separator`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code
(or vice-versa), making it almost seamless.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138826
Sometimes, the default size of the search box is not wide enough for the items
it shows. Currently, we sometimes hardcode an extra width factor and rely on
automatic name shortening with `...`. Both options are not ideal because they
are either often too wide or are hard to read with shortened names.
This patch implements an alternative solution. It adds a new function that
computes a good width for the search box based on its content. A certain minimum
and maximum width are still enforced.
Right now, this feature is only used in the Ctrl+F search in node editors, but I
guess it makes sense in most search boxes.
This also fixes#138641. While it's nice to have ways to use shorter search
terms, the search box should generally be able to deal with long items too.
Pull Request: https://projects.blender.org/blender/blender/pulls/138653
This converts the public `uiItemFullR` function to an object oriented
API (an overload of `uiLayout::prop`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138683
Briefly about this change:
- OpenColorIO C-API is removed.
- The information about color spaces in ImBuf module is removed.
It was stored in global ListBase in colormanagement.cc.
- Both OpenColorIO and fallback implementation supports GPU drawing.
- Fallback implementation supports white point, RGB curves, etc.
- Removed check for support of GPU drawing in IMB.
Historically it was implemented in a separate library with C-API, this
is because way back C++ code needed to stay in intern. This causes all
sort of overheads, and even calls that are strictly considered bad
level.
This change moves OpenColorIO integration into a module within imbuf,
next to movie, and next to IMB_colormanagement which is the main user
of it. This allows to avoid copy of color spaces, displays, views etc
in the ImBuf: they were used to help quickly querying information to
be shown on the interface. With this change it can be stored in the
same data structures as what is used by the OpenColorIO integration.
While it might not be fully avoiding duplication it is now less, and
there is no need in the user code to maintain the copies.
In a lot of cases this change also avoids allocations done per access
to the OpenColorIO. For example, it is not needed anymore to allocate
image descriptor in a heap.
The bigger user-visible change is that the fallback implementation now
supports GLSL drawing, with the whole list of supported features, such
as curve mapping and white point. This should help simplifying code
which relies on color space conversion on GPU: there is no need to
figure out fallback solution in such cases. The only case when drawing
will not work is when there is some actual bug, or driver issue, and
shader has failed to compile.
The change avoids having an opaque type for color space, and instead
uses forward declaration. It is a bit verbose on declaration, but helps
avoiding unsafe type-casts. There are ways to solve this in the future,
like having a header for forward declaration, or to flatten the name
space a bit.
There should be no user-level changes under normal operation.
When building without OpenColorIO or the configuration has a typo or
is missing a fuller set of color management tools is applies (such as the
white point correction).
Pull Request: https://projects.blender.org/blender/blender/pulls/138433
This converts the public `uiItemL` function to an object oriented
API (`uiLayout::label`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138608
This adds basic templating support to render output paths. By putting
"{variable_name}" in the path string, it will be replaced by the named
variable's value when generating the actual output path. This is similar
to how "//" is already substituted with the path to the blend file's
current directory.
This templating system is implemented for both the primary render output
path as well as the File Output node in the compositing nodes. Support
for using templates in other places can be implemented in future PRs.
In addition to the "{variable_name}" syntax, some additional syntax is
also supported:
- Since "{" and "}" now have special meaning, "{{" and "}}" are now
escape sequences for literal "{" and "}".
- "{variable_name:format_specifier}", where "format_specifier" is a
special syntax using "#", which allows the user to specify how numeric
variables should be formatted:
- "{variable_name:###}" will format the number as an integer with at
least 3 characters (padding with zeros as needed).
- "{variable_name:.##}" will format the number as a float with
precisely 2 fractional digits.
- "{variable_name:###.##}" will format the number as a float with at
least 3 characters for the integer part and precisely 2 for the
fractional part.
For the primary render output path: if there is a template syntax error,
a variable doesn't exist, or a format specifier isn't valid (e.g. trying
to format a string with "##"), the render that needs to write to the
output path fails with a descriptive error message.
For both the primary and File Output node paths: if there are template
syntax errors the field is highlighted in red in the UI, and a tooltip
describes the offending syntax errors. Note that these do *not* yet
reflect errors due to missing variables. That will be for a follow-up
PR.
In addition to the general system, this PR also implements a limited set
of variables for use in templates, but more can be implemented in future
PRs. The variables added in this PR are:
- `blend_name`: the name of the current blend file without the file
extension.
- `fps`: the frames per second of the current scene.
- `resolution_x` and `resolution_y`: the render output resolution.
Pull Request: https://projects.blender.org/blender/blender/pulls/134860
This converts the public `uiLayoutRadial` function to an object oriented
API (`uiLayout::menu_pie`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
`uiLayout::menu_pie` now returns an `uiLayout` reference instead of a pointer.
New calls to this method should use references too.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138563
Several small improvements to the layout of the search menu:
* Avoid the separator arrow on highlighted items being cutoff
* Properly center and prevent overlap of the scroll indicator
arrows at the top and bottom
* Improve robustness with different zoom levels
* Overall more unified spacing and margins
This patch was originally authored by Yevgeny Makarov (@jenkm).
Pull Request: https://projects.blender.org/blender/blender/pulls/112422
This converts the public `uiLayoutSplit` function to an object oriented
API (`uiLayout::split`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
`uiLayout::split` now returns an `uiLayout` reference instead of a pointer.
New calls to this method should use references too.
Pull Request: https://projects.blender.org/blender/blender/pulls/138361
Tooltips for enum items currently show the enum name on one line, then
enum description, then the current value's name, then the value's
description on the next line. This PR changes that to display the
(short) names together then the (longer) descriptions together. This
also adds a small amount of padding under the title.
Pull Request: https://projects.blender.org/blender/blender/pulls/137571
This converts the public `uiLayoutColumn` function to an object oriented
API (`uiLayout::column`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
`uiLayout::column` now returns an `uiLayout` reference instead of a pointer.
New calls to this method should use references too.
Pull Request: https://projects.blender.org/blender/blender/pulls/138034
It's safer to pass a type so that it can be checked if delete should be
used instead. Also changes a few void pointer casts to const_cast so that
if the data becomes typed it's an error.
Pull Request: https://projects.blender.org/blender/blender/pulls/137404
This error is technically correct when the operators path doesn't
support relative paths.
The collection exporter allows relative paths and expands them before
passing the value to the operator.
Resolve by suppressing the warning.
Ref: !137510
Some paths in Blender support the `//` prefix for blend-file relative
paths however this is not communicated anywhere.
Support declaring this with a new flag which can be applied to filepath
& dirpath typed properties.
This is used to:
- Show red-alert when "//" are used in paths which don't support a relative prefix.
- Show a warning in the tooltip that the relative suffix is used when unsupported.
- Python warns if this prefix is ever used in an assignment or
function argument.
Resolves#133456.
Ref !137060
Part of incoming refactors in interface layout c++ code, this enables
forward declaring this enum type. Enum is renamed as `EmbossType` and
moved to `blender::ui` namespace. No user visible changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/136725
- Manually check over all direct calls to operator callbacks
ensuring the result isn't assigned to an int.
- OPERATOR_RETVAL_CHECK() now fails unless a wmOperatorStatus is used.
- Check the return values of direct calls to callbacks.
- Remove invalid check for the return value of rna_operator_check_cb.
- Use the variable name `retval` as it's most widely used.
- Move the assignment of `retval` out of the `if` statement in
sculpt/paint operators because it prevents assigning the result
`const` variable.
Callbacks: exec invoke & modal now use a typed enum wmOperatorStatus.
This helps avoid mistakes returning incompatible booleans or other
values which don't make sense for operators to return.
It also makes it more obvious functions in the WM API are intended
to be used to calculate return values for operator callbacks.
Operator enums have been moved into DNA_windowmanager_enums.h
so this can be used in other headers without loading other includes
indirectly.
No functional changes expected.
Ref !136227
For tooltips, use typographical line breaking with hard limit for uses
of the regular font, path wrapping with hard limit for uses of the
monospaced font. Small correction to wrapping code so that hard limit
is not taken if there are optional breaking points.
Pull Request: https://projects.blender.org/blender/blender/pulls/136148
Using `UI_but_func_tooltip_custom_set()` to create a custom tooltip
would completely disable the quicker label tooltip, even when explicitly
set using `UI_but_func_tooltip_label_set()`. Instead the quick label
should show first, and then the full tooltip once the usual tooltip
timer is reached.
We are showing full paths to the library file on some tooltips, like
for brush assets. This PR checks to see if the asset is in the
BLENDER_SYSTEM_DATAFILES/assets folder. If so it just shows it as
"Built-in Asset:" and with the last portion of the path.
Pull Request: https://projects.blender.org/blender/blender/pulls/135593
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
And replace nullptr arguments for tooltips in UI button
creation functions with std::nullopt. Though the distinction
between "no tooltip" and "empty tooltip" doesn't seem to exist,
it seems safer to keep the distinction since it existed with null before.
This changes the ui-blocks buttons storage from Listbase to Vector.
Major changes that might cause a performance considerations are
in `ui_but_update_from_old_block` that requires to track buttons when restoring
button state between block redraws or in `uiItemFullR` that may needs to insert
uiButs in the middle of the vector to add decorators. This might not be as fast as
removing or inserting elements in the middle of a listbase container. Also buttons currently
don't know its position in the container, so to get the previous and next
button its required to make a lookup of the button in the container.
`UI_block_update_from_old> ui_but_update_from_old_block` restores the state
of buttons between frames, this is done by sequentially testing if a button is the
same as an old button, however since UI can be created procedurally some old buttons
may not be drawn while editing other button data, this requires an extra track of what
buttons may not match to a new button while comparing for restoring state, but still
this buttons may be candidates to match to an new button.
Not functional changes expected.
Ref: #117604
Co-authored-by: Julian Eisel <julian@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/127128
The UI code assumed buttons had no more than 4 elements
however Python scripts may define larger array sizes.
Resolve the bug by adding functions for array access that take an
array size limit to prevent buffer overflows (read & write).
Note that this only adds the "float" versions of these functions,
for completeness int & boolean can be supported as a separate commit.
The "Red Alert" color is currently hard-coded, which causes problems in
themes. It also has an Enum value of 0, which precludes using this
value as "unset". We also use Error, Warning, and Info colors that are
part of the Info Editor. This PR moves these out of the Info Editor
and into the "State" part of the theme. And then makes TH_REDALERT use
the TH_ERROR color.
Pull Request: https://projects.blender.org/blender/blender/pulls/131127
Refactor how tooltips are sized, items placed, margins calculated, etc.
Current code has some mistakes that we use kludges to compensate for,
and it doesn't properly consider the font size in calculating margins.
The result shown to users in normal circumstances (changing resolution
scale only) with this PR applied should look identical to current.
Small changes when the text style size is changed. However, this is
mostly to allow later adjustments to padding, which currently _breaks_
when changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/134205
Another case of C-style allocation of non-trivial objects hidden
with casting. To fix, give explicit member defaults to a few of
the UI interaction structs.
Move `Library.runtime` to be a pointer, move the related
`LibraryRuntime` struct to `BKE_library.hh`. Similar to e.g.
Mesh.runtime, that pointer is expected to always be valid, and is
allocated at readtime or when creating a new Library ID.
Related smaller changes:
* Write code now uses standard ID writing codepath for Library IDs too.
* Runtime pointer is reset to nullptr before writing.
* Looking up a library by its absolute path is now handled through a
dedicated utils, `search_filepath_abs`, instead of using
`BLI_findstring`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134188
