Optionally use regular expressions for the destination name,
allows re-ordering words while renaming.
Initial patch by @jmztn with error handling and UI changes.
This adds a url-preset operator to simplify opening re-usable links.
- Standard websites have their own tool-tip.
- De-duplicate logic to get URL's that include version information.
- Reporting bugs no longer needs to have all information
included in the URL.
D5498 by @luisbg with edits.
To fully support storing colors as a custom property, it is necessary
to allow switching the property UI to the standard color picker button.
That means in effect supporting custom property subtype values.
Change RNA_property_subtype to look for a 'subtype' string field
in _RNA_UI and parse it as an enum value. To minimize performance
impact, only do it if the property is an array; also, don't use
the custom subtype during RNA path parsing.
On the python side, allow setting some most useful seeming values
from the custom property settings editor.
Also, since some color picker code seems to run into a risk of
buffer overruns if the array size is wrong, check the size in
the UI layout code to be safe.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D5475
In some rare cases it is convenient to store a short array value
as a custom property, e.g. a vector or color. For example, it may
be helpful when importing/exporting certain formats that support
custom or nonstandard attributes on objects.
The custom property storage already can handle arrays in order to
support properties defined via python. The only thing missing is
UI support (and some bugs), and this patch fixes that:
- Allow editing short array properties via Custom Properties panel.
- Fix a UI layout sizing bug triggered by the previous item.
- Fix a dependency graph bug with drivers using such properties.
- Make RNA_*_get_default_array code robust in case of size mismatch.
- Support custom default values for array properties, allowing
both an array and a scalar value.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D5457
We want users to go to the current version for their current version
when possible if not point to latest.
/dev should really only be for development related work. End users
should not be browsing /dev unless they are reading about upcoming
features ahead of time.
Better to make internal code naming match official/UI naming to some
extent, this will reduce confusion in the future.
This is 'breaking' scripts and files that would use that feature, but
since it is not yet officially supported nor exposed in 2.80, as far
as that release is concerned, it is effectively
a 'no functional changes' commit.
The complexity in this patch comes from the fact
that the current operator system does not support
multi-step user interactions well.
More specifically, for this to work, we need to show
a confirm dialog and a file browser afterwards.
We decided that it is easier to keep everything in
a single operator, instead of creating separate
operators that invoke each other.
So, now the `WM_OT_open_mainfile` operator invokes
itself in different states. It implements a simple
finite state machine to manage the states.
The dialog itself is expected to be improved in
a future commit. See D4829 for more details.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4829
- Add missing tooltips to Quick Effects and Subdivide Edge Ring
- Add proper tooltip to the Bevel operator
- Clearer tooltips for the extrude operators
Plus a few other tweaks
Suggested by users on Devtalk.
Creating a fully functional custom property requires also setting up
its limits, description, default value and static override status.
It is complex enough to warrant providing an official utility.
Currently boolean properties are technically int, but the utility
pretends they are separate in case that eventually they are.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D4620
Prepare for exposing tool registration to the Python API.
- Generated tools can use their own prefix so naming collisions
won't happen between hard coded & generated tools.
- Add-on authors can use the add-on name as a prefix.
Currently the names match, renaming will happen next.
