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
This converts the public `uiLayoutListBox ` and `uiLayoutOverlap `
functions to an object oriented API (an `uiLayout::list_box` and
`uiLayout::overlap` respectively), following recent uiLayout changes.
Both functions 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/138559
This converts the public `uiLayoutAbsolute ` and `uiLayoutAbsoluteBlock`
functions to an object oriented API (an `uiLayout::absolute` and
`uiLayout::absolute_block` respectively), following recent changes.
`uiLayout::absolute` 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/138546
This converts the public uiLayoutPanelPropWithBoolHeader function to an
object oriented API (`uiLayout::panel_prop_with_bool_header`), following
similar changes to the uiLayout API.
Pull Request: https://projects.blender.org/blender/blender/pulls/138523
This converts the public `uiLayoutPanelProp` function to an object oriented
API (`uiLayout::panel_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.
Pull Request: https://projects.blender.org/blender/blender/pulls/138501
This converts the public `uiLayoutPanel` function to an object oriented
API (`uiLayout::panel`), 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.
Pull Request: https://projects.blender.org/blender/blender/pulls/138461
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
This converts the public `uiLayoutBox` function to an object oriented
API (`uiLayout::box`), 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::box` 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/138334
Fixes for #137856 & #137507 were workarounds to ignore the
PROP_PATH_SUPPORTS_BLEND_RELATIVE for CollectionExport however they
were error prone - especially #137856 as it relied on the surrounding
buttons.
Instead of adding logic to ignore the flag for this specific case,
add a property to the CollectionExport which can have it's flags
and use this instead of the operators "filepath" property.
Internally this wraps the same IDProperty data used by the operator.
Ref !137883
This converts the public `uiLayoutColumnFlow` and `uiLayoutGridFlow` functions
to an object oriented API (an `uiLayout::column_flow` and `uiLayout::grid_flow` respectively),
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.
Both renamed functions 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/138074
This converts the public `uiLayoutColumnWithHeading` function to an
object oriented API (an `uiLayout::column` overloaded version), matching
the python API.
Like the original `uiLayout::column`, this overloaded version now also
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/138056
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
This converts the public `uiLayoutRowWithHeading` function to an object oriented
API (an `uiLayout::row` overloaded version), 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.
Same as the original `uiLayout::row`, this overloaded version also 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/138014
This converts the public `uiLayoutRow` function to an object oriented
API (`uiLayout::row`), 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::row` 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/137979
Add another exception for collection exporting (similar to #137507).
It's possible to avoid these workaround but this involves bigger changes
which are likely API breaking.
Move most `uiLayout` and `uiItem` functions to a separate
`UI_interface_layout.hh` header file. `uiItem` and `uiLayout` structs
are moved from `interface_layout.cc` to `UI_interface_Layout.hh` in
preparation for switching to an object oriented API style.
`UI_block_layout*` functions are moved to `UI_interface_Layout.hh` too,
since their implementation is also in `interface_layout.cc`
Types shared by `UI_interface_Layout.hh` and `UI_interface_c.hh`
are moved to `UI_interface_types.hh`.
Ref: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/136717
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
This commit allows to specialize or optimize properties editor for
particular workflows by hiding individual tabs. The filtering is done on
editor level, currently in editor options popover panel.
Primary motivation was to allow strip properties to be moved to
properties editor. The filtering is beneficial, as usually it does not
make sense to show strip propeties in modelling workspace and in video
editing workspace other properties would introduce quite a bit of noise.
Ref. #115626
Pull Request: https://projects.blender.org/blender/blender/pulls/115624
Part of incoming refactors in interface layout C++ code, this enables
forward declaring this enum type outside of `layout_interface.cc`. The
enum is renamed as `ItemInternalFlag` and moved to the `blender::ui`
namespace. `uiItemInternalFlag` is preserved as a shorthand for
`blender::ui::ItemInternalFlag`.
No user visible changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/136782
Part of incoming refactors in interface layout C++ code, this enables
forward declaring this enum type outside of `layout_interface.cc`. The
enum is renamed as `ItemType` and moved to the `blender::ui` namespace.
`uiItemType` is preserved as a shorthand for `blender::ui::ItemType`.
No user visible changes expected, layout introspection will still print
item types using property enum identifier format.
Pull Request: https://projects.blender.org/blender/blender/pulls/136740
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
Add support for a 5th modifier key called "hyper",
this is a modifier supported on Wayland & X11 although
other platforms could support an additional modifier too.
Both GNOME and KDE can map CapsLock to Hyper.
Other compositors can use the XKB_DEFAULT_OPTIONS environment variable.
This allows users to have an additional modifier for their own use
that doesn't conflict with other keys.
Ref !136340
This will likely reserve a larger vector more than actually needed.
Reserve only the same count of decorators to be added, since they
likely match the number of buttons that needs to be temporally
retrieved.
Decorators buttons are added along animatable property buttons in each
`layout.prop` function call, when a property is a `XYZ` vector property,
drawing this property adds 3 inputs buttons and for each inputs buttons
this need to insert an aligned property decorator, since this decorators
are added just after the buttons are added this likely just takes out
temporally this last 3 elements and inserts them back with each
corresponding decorator.
Pull Request: https://projects.blender.org/blender/blender/pulls/136191
Caused by 21aef81714
Now, pass along `uiname` as `std::optional<StringRef>` early on (and use
`std::nullopt`).
Without this, the `(!uiname || !uiname->is_empty())` condition in
`ui_item_enum_expand_elem_exec` wont be true, resulting in the empty
label.
Pull Request: https://projects.blender.org/blender/blender/pulls/135621
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
Adds the option to create a boolean socket that can be used as a panel toggle.
This allows creating simpler and more compact node group UIs when a panel
can be "disabled".
The toggle input is a normal input socket that is just drawn a bit differently in
the UI. Whether a boolean is a toggle input or not does not affect evaluation.
Also see #133936 for guides on how to add and remove panel toggles.
Pull Request: https://projects.blender.org/blender/blender/pulls/133936
Slight adjustments to the spacing of items on the Status Bar. Mainly
to reduce the distance between adjoining icons. Small decrease in space
between icon and text. Slight decrease in text size inside the event
icons. Proportionally wider gap between items.
Pull Request: https://projects.blender.org/blender/blender/pulls/134534
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
