Add frequently-used Chinese, Japanese, Korean special character
delimiters (punctuation, quote characters, brackets, etc) to aid the
selection of character segments in text operations.
Pull Request: https://projects.blender.org/blender/blender/pulls/112852
The logic to handle word selection from double clicking ran even when
the event wasn't inside the button. This would pass an invalid position
to BLI_str_cursor_step_bounds_utf8 which hung.
Resolve by limiting word-selection to when the event is inside
the text editing field as well as clamping the position to ensure
it's within the allowed range.
When using menu search, each search item has multiple segments. In the UI,
we only highlight last section, which is the actual node/operator name. The
menu path is grayed out. It seems reasonable to give greater weight to the
words in the search item that are highlighted.
See #112839 for an example of what effect this can have.
Pull Request: https://projects.blender.org/blender/blender/pulls/112839
The goal is to make the search faster to use by dynamically adapting to the user.
This can be achieved using the simple but common approach of showing recently
selected items at the top. Note, that the "matching score" between the query and
each search item still has precedence when determining the order. So the last used
item is only at the top, if there is no other search item that matches the query better.
Besides making the search generally faster to use, my hope is that this can also
reduce the need for manually weighting search items in some places. This is
because while the ordering might not be perfect the first time, it will always be
once the user selected the element that should be at the top once.
This patch includes:
* Support for taking recent searches into account in string searching.
* Keep track of a global list of recent searches.
* Store recent searches on disk similar to recently opened files.
* A new setting in the user preferences that allows disabling the functionality.
This can be used if deterministic key strokes are required, e.g. for automated tests.
In the future this could be improved in different ways:
* Add some kind of separator in the search list to indicate which elements are at
the top because they have been used recently.
* Store the recent search items per search, instead of in a global list. This way
it could adapt to the user even better.
Pull Request: https://projects.blender.org/blender/blender/pulls/110828
Ensure the string isn't null terminated before len, if this happens
it's likely an error calculating the length argument. Since the length
is passed to memcpy it could result in reading outside `str` bounds.
There was one case where the string was duplicated then grew by 1 byte
afterwards. Replace this with an allocation since it's an uncommon
operation, not especially useful to support.
Make type conversions explicit so it's clear when char/char32_t/uint
values are being mixed, also use int instead of size_t for cursor
functions because the cursor is an int - which caused many int/size_t
comparisons.
This makes it clearer other "safe" functions should be used in
combination with the resulting offsets.
Also correct doc-string which wasn't updated from the "or_error()"
version of this function.
The functions used to calculate the UTF8 code-points already used the
safe versions (count_utf8_code_points & BLI_str_utf8_as_unicode_step).
So it makes sense to use safe accessors elsewhere too.
There were enough cases of callers ignoring a potential the error value,
using the column width for e.g. to calculate pixel sizes, or the size in
bytes to calculate buffer offsets.
Since text fields & labels can include characters that return an error
from BLI_str_utf8_as_unicode, add the suffix to make this explicit.
Strings that include Latin1 encoding or corrupt UTF8 byte sequences
could read past the buffer bounds (stepping over the null terminator).
Resolve by passing in the string length.
Other changes to support non-UTF8 byte sequences:
- BLI_str_utf8_offset_{to/from}_index were accumulating
the UTF8 offset without accounting for non-UTF8 characters
which could cause a buffer underflow or enter an eternal loop.
- BLI_str_utf8_offset_to_index would read past the buffer bounds if the
offset passed in if it was in the middle of a UTF8 byte sequence.
Change to handling of control characters in [0] caused tests to fail,
now the cursor no longer skips over control characters,
update test to account for this.
[0]: bc51449ff1
BLI_str_utf8_char_width returns -1 for character without a known width.
This caused the right cursor motion to skip these characters.
While editable text should not contain control characters,
cursor motion should behave properly in cases when they do.
Since hiding symbols on Linux, in many cases only addresses are printed.
This utility can run run on the back-trace to replace addresses
with line & function information.
See: ./tools/utils/addr2line_backtrace.py --help for usage information.
Note that some examples online run addr2line directly and use the output
in the stack-trace, while convenient and acceptable in some cases, in my
tests addr2line can take over 20 seconds to complete for a single
address. Implement this as a post-process instead. Multi-processing to
prevent this taking too long (around ~23 seconds on my system).
Ref !111416.
This fixes#111767
`In Front` objects remain visible even if they are behind non
`In Front` objects.
It is to be expected then that the snap for them is not occluded as if
they were not `In Front`.
The f12e9f32b5 patch introduced a new improved method of blending
dual quaternion transformations to handle combined scale and rotation
better. However, the changes were not complete:
* The new math ignored crazyspace computations, which need to compute
a complete transformation matrix. As an optimization, the new method
avoided fully computing the scale component, so the matrix would
have no scale or shear.
* The Armature constraint is supposed to behave identically to the
modifier, and it was not updated. The constraint also requires
computing a complete matrix.
This change extracts the new math into a utility function, change
the optimization to be controlled by a parameter, and use the new
function in the constraint.
Pull Request: https://projects.blender.org/blender/blender/pulls/111759
The main goal here is to rename things in a way that makes sense for
simulation baking, but also for the upcoming bake node.
This also removes some versioning code from 3.6 which initialized the
default bake path. Baked data from back then can't be loaded anymore
anyway, and the way the default path is generated is different now as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/111845
The hash tables and vector blenlib headers were pulling many more
headers than they actually need, including the C base math header,
our C string API header, and the StringRef header. All of this
potentially slows down compilation and polutes autocomplete
with unrelated information.
Also remove the `ListBase` constructor for `Vector`. It wasn't used
much, and making it easy to use `ListBase` isn't worth it for the
same reasons mentioned above.
It turns out a lot of files depended on indirect includes of
`BLI_string.h` and `BLI_listbase.h`, so those are fixed here.
Pull Request: https://projects.blender.org/blender/blender/pulls/111801
Goals of the refactor:
* Internal support for baking individual simulation zones (not exposed in the UI yet).
* More well-defined access to simulation data in geometry nodes. Especially, it
should be more obvious where data is modified. A similar approach should also
work for the Bake node.
Previously, there were a bunch of simulation specific properties in `GeoNodesModifierData`
and then the simulation input and output nodes would have to figure out what to do with that
data. Now, there is a new `GeoNodesSimulationParams` which controls the behavior of
simulation zones. Contrary to before, different simulation zones can now be handled
independently, even if that is not really used yet. `GeoNodesSimulationParams` has to be
subclassed by a user of the geometry nodes API. The subclass controls what each simulation
input and output node does. This some of the logic that was part of the node before, into
the modifier.
The way we store simulation data is "transposed". Previously, we stored zone data per
frame, but now we store frame data per zone. This allows different zones to be more
independent. Consequently, the way the simulation cache is accessed changed. I kept
things simpler for now, avoiding many of the methods we had before, and directly
accessing the data more often which is often simple enough. This change also makes
it theoretically possible to store baked data for separate zones independently.
A downside of this is, that existing baked data can't be read anymore. We don't really
have compatibility guarantees for this format yet, so it's ok. Users will have to bake again.
The bake folder for the modifier now contains an extra subfolder for every zone.
Drawing the cached/baked frames in the timeline is less straight forward now. Currently,
it just draws the state of one of the zones, which usually is identical to that of all other
zones. This will change in the future though, and then the timeline drawing also needs
some new UI work.
Pull Request: https://projects.blender.org/blender/blender/pulls/111623
