Similar to other removed UI layout functions, this removes uiItemEnumO*
functions and replaces them by calling `uiLayout::op` and writing enum
properties to the returned RNA pointer.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/141632
This renames UI_block_layout API as blender::ui::block_layout_resolve,
following uiLayout refactors.
This simplifies usage by returning block layout size as C++ int2 instead
of using return parameters, in fact some places were providing
unused variables.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/141432
This renames `UI_block_layout` API as `blender::ui::block_layout`,
following uiLayout refactors.
This function now returns a layout reference instead of pointer,
this changes applies this return type where the layout can be used
as such reference.
Changes includes the use of `blender::ui::LayoutDirection` and
`blender::ui::LayoutType` as typed enum parameters.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/141401
Almost all uiLayout methods that creates sub-layouts returns a uiLayout
reference, API users must use the returned sub-layout to add items,
this prevents a accidental copy that could break Blender.
Pull Request: https://projects.blender.org/blender/blender/pulls/141051
This replaces uiItemMContents, uiItemDecoratorR* and
uiItemProgressIndicator API with uiLayout methods following
uiLayout refactors and the Python API.
`eButProgressType` is changed to a typed enum class
`blender::ui::ButProgressType`
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/141189
This replaces `uiItemFullOMenuHold_ptr`, `uiItemFullR_with_popover`,
`uiItemFullR_with_menu`, `uiItemPopoverPanel`* and `uiItemSpacer` API
with methods following uiLayout refactors and the Python API.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/141050
This replaces API for accessing the uiLayout fixed_size,
red_alert, root_panel, search_weight and width properties
with methods, following uiLayout refactors and the
Python API naming
Pull Request: https://projects.blender.org/blender/blender/pulls/140673
This removes the include `UI_interface_layout.hh` from
`UI_interface_c.hh`, and in many places this swaps the include
from `UI_interface.hh` to `UI_interface_layout.hh`.
Also, cleanups some `UI_interface.hh` includes with
`UI_interface_icons.hh` or `UI_interface_types.hh`
This replaces uiLayout aligment API with uiLayout methods,
following uiLayout refactors and the Python API naming.
Also this converts the layout aligment enum to a fixed enum class.
Pull Request: https://projects.blender.org/blender/blender/pulls/140622
This replaces API for accessing the uiLayout active_default,
acviated_init, enabled properties with methods, following uiLayout
refactors and the Python API naming.
Pull Request: https://projects.blender.org/blender/blender/pulls/140226
The path templates feature implemented in #134860 highlights path
properties that have syntax errors in red and provides a list of those
errors in the path's tool tip. However, syntax errors are not the only
kind of error.
For example, if given the render output path `//render/{blend_nam}`,
with a typo in the variable `blend_name`, this error is not indicated
until actually trying to render. This is because the path is
*syntactically* correct, and the error is due to `blend_nam` not being
an available variable.
This PR resolves this: paths with path template support now indicate all
errors in the UI, not just syntax errors, with red highlights and a list
of errors in the tool tip.
The primary mechanisms for this are:
- A new function `BKE_build_template_variables_for_prop()`, which takes
an RNA pointer and produces an appropriate template variable map for the
given property, which can then be used to fully validate a path
property's value in the UI code.
- A new enum `PropertyPathTemplateType` has been added to `PropertyRNA`,
which determines what variables should be made available to a property
and how they should be build. This is used by
`BKE_build_template_variables_for_prop()`.
Additionally, the following changes have been made to help ensure that
`BKE_path_apply_template()` and `BKE_path_validate_template()` produce
identical errors:
- Both functions now call into a third static function `eval_template()`
that does the actual work, optionally modifying the input path or not.
- Previously only `BKE_path_apply_template()` had unit tests, but now
the unit tests have been reorganized to simultaneously test both
`BKE_path_apply_template()` and `BKE_path_validate_template()`.
Pull Request: https://projects.blender.org/blender/blender/pulls/138679
This function has not python equivalent, using the
returned pointer to write properties seems enough
as equivalent as how is done in python.
Also, this removes the unused `uiItemFloatO` API.
Pull Request: https://projects.blender.org/blender/blender/pulls/139355
This was an alternative way to write properties for layout operator buttons,
for the most cases are more than enough to use the returned pointer.
There were just 2 cases where this was useful, the quick access menu
that reuses operator property values, this now overrides the id property group
data pointer generated for the operator, also for `uiItemsFullEnumO_items`.
Pull Request: https://projects.blender.org/blender/blender/pulls/139242
Use a similar convention for struct member identifiers,
(the identifiers without surrounding spaces). This allows the values
to be scanned and validated.
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
This converts the public `uiItemFullO` function to an object oriented
API (an `uiLayout::op` overload), matching recents changes in the API.
Changes includes the removal of the paramether `IDProperty *properties`
that seems unused (all places just sets `nullptr`, can be added as last
argument with `nullptr` as default value though), and instead of using a
return paramether the function now returns the pointer to write properties.
Pull Request: https://projects.blender.org/blender/blender/pulls/138961
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 converts the public `uiItemMenuF` and `uiItemMenuFN`
functions to an object oriented API (an `uiLayout::menu_fn`
and `uiLayout::menu_fn_argN_free` respectively), following
recent uiLayout changes.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138902
Improve labels and UI consistency.
- Update color labels: Object, Wireframe, Background
- Rename 'Single' shading color to 'Custom'. Move to the end.
- Rename 'Viewport' color to 'Custom' for consistency.
- Fix alignment of Object Color item labels
Pull Request: https://projects.blender.org/blender/blender/pulls/137408
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
This converts the public `uiItemO` function to an object oriented
API (`uiLayout::op`).
Also this rearranges `idname` paramether, since this the only one
required, and to make format similar to `uiItemFullO`
Note: One of the benefits of moving from a public function to class
method is to reduce API usage difference between C++ and Python. In
Python this method is called `UILayout::operator`, however `operator`
is a reserved keyword in C++.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138776
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
This converts the public `uiItemR` function to an object oriented
API (`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/138617
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
Previously, it was possible to search for specific math operations in
link-drag-search but not in the normal add menu. This patch adds support for
searching for specific operations in various math nodes.
A good trick for adding e.g. a vector add node is to search for `vadd`
(similarly with `iadd`).
The menu itself looks unchanged. This patch only adds additional elements to the
search.
Pull Request: https://projects.blender.org/blender/blender/pulls/138534
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
