Improve a few messages, but mostly fix typos in many areas of the UI.
See inline comments in the differential revisiion for the rationale
behind the various changes.
Differential Revision: https://developer.blender.org/D16716
I18n: make a few messages translatable
* Missing Paths * in the Presets menu when no preset exists yet.
The White Noise entry in the Add Node menu is the only one lacking a "Texture" suffix, which doesn't seem justified since the node itself is already called "White Noise Texture". Rename the entry its name can be extracted and used for the node--and for consistency.
New object material node names (Principled BSDF, Material Output) come from a preset node tree. The nodes' names need to be translated after creation.
Extract the "Fallback Tool" pie menu title.
Translate grease pencil options in the viewport overlay menu.
Ref T102030.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D16345
Many reports and a few labels used string formatting without
explicitly calling tip_() or iface_(), so the untranslated message
was used instead of the translated one, even when it was extracted.
Differential Revision: https://developer.blender.org/D16405
The property assignment operators' tooltips were never actually
translated when they were constructed dynamically from the description
in the prop's RNA.
This was visible when using such operators in menus (example I found
was the Marker Settings, Shift + E in the Movie Clip Editor).
"%s: %s" is already extracted elsewhere, might as well use it.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D16439
- The label for modal keymaps was extracted but did not use the proper
context on translation.
- Same goes for modal keymap items.
- Extract the UI messages from rna_keymap_ui.py
- Translate global keymap names.
- Use the proper context in the status bar for the tool prompt operator
Ref T102071
Maniphest Tasks: T102071
Differential Revision: https://developer.blender.org/D16348
Show the windowing environment on non MS-Windows/Apple systems,
since X11/WAYLAND are selected startup there was no convenient way
for users to know which back-end was being used.
Include the windowing environment in the About splash & system-info.txt
since it will be useful for handling bug reports.
This commit adds a private API call not intended for general use
as I would like to be able to remove this later and it's only needed
in the specific case of testing if Blender is using WAYLAND or X11
(which maybe be used via XWayland).
Python scripts can already inspect the system to check which windowing
environment used, the API call is mainly useful for troubleshooting.
- batch rename
- keyframe settings
- tool name in Tool properties header
- tool name in Tool properties Drag (fake) enum
- new file templates
- new preset
- new text datablock
- new collection datablock
- new geometry nodes (modifier and node group)
- new grease pencil data (layers and materials)
Ref. T43295
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15533
There is no need to have use/is in the final name. This is implicitly
represented by the checkbox already.
This does not change the Python API, only the names we show in the user
interface.
* Is Library Overridable -> Library Overridable
* Use Soft Limits -> Soft Limits
Differential Revision: https://developer.blender.org/D15217
It can be assumed that all scripts comply with basic pep8 formatting
regarding white-space, indentation etc.
Also remove note in best practices page & update `tests/python/pep8.py`.
If we want to exclude some scripts from make format,
this can be done by adding them to `ignore_files` in:
source/tools/utils_maintenance/autopep8_format_paths.py
Or using `# nopep8` for to ignore for individual lines.
Ref T98554
When expanding the data path for the context, use Context.temp_override
to extract context members. Without this, only context-members available
in the preferences were used which misses members which are likely to
be useful.
Iterate over all windows, areas and regions showing unique member as
candidates. The search is limited to WINDOW/PREVIEW region types, the
preferences space type is also excluded. See the doc-string for
rna_path_prop_search_for_context for additional notes on this.
Currently strings are used for cases where a list of identifiers would
be useful to show.
Add support for string properties to reference a callback to populate
candidates to show when editing a string. The user isn't prevented from
typing in text not found in this list, it's just useful as a reference.
Support for expanding the following strings has been added:
- Operator, menu & panel identifiers in the keymap editor.
- WM operators that reference data-paths expand using the
Python-consoles auto-complete functionality.
- Names of keying sets for insert/delete keyframe operators.
Details:
- `bpy.props.StringProperty` takes an option `search` callback.
- A new string callback has been added, set via
`RNA_def_property_string_search_func` or
`RNA_def_property_string_search_func_runtime`.
- Addresses usability issue highlighted by T89560,
where setting keying set identifiers as strings isn't practical.
- Showing additional right-aligned text in the search results is
supported but disabled by default as the text is too cramped in most
string search popups where the feature would make sense. It could be
enabled as part of other layout tweaks.
Reviewed By: brecht
Ref D14986
Recently we changed the build pipeline to always create a version
number in the url and point 'dev' to the latest version rather than creating the version number url once we release.
This makes the check to `bpy.app.version_cycle` unnecessary.
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
Some items on the Quick Setup screen can be truncated with some
languages and/or with High DPI monitors. This patch adjusts column
sizes and turns off the expand on Spacebar options, making everything
fit a bit better.
See D9853 for more details.
Differential Revision: https://developer.blender.org/D9853
Reviewed by Julian Eisel
This patch makes the layout of the custom property panel more coherent
with the rest of the property editor interface, makes it less busy,
allows more space for the buttons for the actual properties, and
simplifies editing values of unsupported property types or long arrays.
- Remove the box around each property.
- Use an non-embossed X icon for deleting.
- Use an "edit" icon instead of the text for the meta-data edit operator.
The "gear" icon used for editing isn't ideal here.
- Increase the max array length for drawing the values directly to 8.
- Add an "Edit Property Value" operator for dictionaries or longer arrays.
- Replace the "Library Override" text with an icon.
- Use a proper split factor, the same as the rest of the UI.
Differential Revision: https://developer.blender.org/D12805
- Fix a typo that used the max instead of the min for the soft max
- Assign the correct "last property type" when the operator starts
- Only check values for the soft range when use soft range is turned on
This commit changes the custom property edit operator to make editing
different properties types more obvious and expose more of the data,
made more easily possible by the recent UI data refactor.
Previously, the operator guessed the type you wanted based on what you
wrote in a text box. That was problematic, you couldn't make a string
property with a value of `1234`, and you had to know about the Python
syntax for lists in order to create an array property. It was also slow
and error prone; it was too easy to make a typo.
Improvements compared to the old operator:
- A type drop-down to choose between the property types.
- Step and precision values are exposed.
- Buttons that have the correct type based on the property.
- String properties no longer display min, max, etc. buttons.
- Generally works in more cases. The old operator tended to break.
- Choose array length with a slider.
- Easy to choose to use python evaluation when necessary.
- Code is commented, split up, and much easier to understand.
The custom property's value is purposefully not exposed, since the Edit
operator is for changing the property's metadata now, rather than the
value itself. Though in the "Python" mode the value is still available.
More improvements are possible in the future, like exposing different
subtypes, and improving the UI of the custom properties panel.
Differential Revision: https://developer.blender.org/D12435
Added description for Batch rename which pop-ups when
hovering the mouse over "Batch rename" inside the edit menu.
Fixes T91390
Reviewed By: Blendify
Maniphest Tasks: T91390
Differential Revision: https://developer.blender.org/D12594
Initializing the description property was completely forgotten.
It also seems it may be missing sometimes, so use `get`.
Also, clean values when there is no data, and correctly use
the return value of `get_value_eval` in one instance.
This commit fixes the custom property edit operator for the the case of
editing group properties. Currently this isn't supported very well, the
data is converted to a string, but the operator shouldn't fail anyway.
This allows editing properties created like this:
C.object['abuse'] = {'parent' : ['child1', 'child2']}
These changes reflect some issues with the design of the operator.
Requiring guessing the type of the data does not work well at all, and
makes code more complicated. In the future this operator can be updated
to use a type drop-down.
Differential Revision: https://developer.blender.org/D12364
This commit fixes editing the value of a list of strings custom property
with the "Custom Property Edit" operator. This sort of custom property
isn't very well supported in general, but editing the values should
work properly anyway.
Differential Revision: https://developer.blender.org/D12348
The storage of IDProperty UI data (min, max, default value, etc) is
quite complicated. For every property, retrieving a single one of these
values involves three string lookups. First for the "_RNA_UI" group
property, then another for a group with the property's name, then for
the data value name. Not only is this inefficient, it's hard to reason
about, unintuitive, and not at all self-explanatory.
This commit replaces that system with a UI data struct directly in the
IDProperty. If it's not used, the only cost is of a NULL pointer. Beyond
storing the description, name, and RNA subtype, derived structs are used
to store type specific UI data like min and max.
Note that this means that addons using (abusing) the `_RNA_UI` custom
property will have to be changed. A few places in the addons repository
will be changed after this commit with D9919.
**Before**
Before, first the _RNA_UI subgroup is retrieved the _RNA_UI group,
then the subgroup for the original property, then specific UI data
is accessed like any other IDProperty.
```
prop = rna_idprop_ui_prop_get(idproperties_owner, "prop_name", create=True)
prop["min"] = 1.0
```
**After**
After, the `id_properties_ui` function for RNA structs returns a python
object specifically for managing an IDProperty's UI data.
```
ui_data = idproperties_owner.id_properties_ui("prop_name")
ui_data.update(min=1.0)
```
In addition to `update`, there are now other functions:
- `as_dict`: Returns a dictionary of the property's UI data.
- `clear`: Removes the property's UI data.
- `update_from`: Copy UI data between properties,
even if they have different owners.
Differential Revision: https://developer.blender.org/D9697
Use utility functions to decompose data paths and resolve the
RNA property from a data-path.
Replaces in-line string manipulation and RNA access.
This allows more complex data paths to be used, where previously string
literals in a data path could break the simple data-path handling logic.
