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
This add the possibility to create a
orthogonal basis around a given unit
vector.
The name was chosen to match the naming
convention already in place and match
the other matrix construction functions.
In other places (ex: renderers), this same
function is commonly named `make_orthonormal`
or `make_basis`.
The function is not given to have a fixed
implementation and might change overtime.
That's why the test only covers the
assumptions and not the raw values.
The implementation is borrowed from
Cycles and adapted to our math API.
Pull Request: https://projects.blender.org/blender/blender/pulls/113218
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.
MSVC 17.7 generates bad code in some lambda's, this has been reported
upstream [1], and a workaround has been suggested by MS in the form of
turning the inliner off. In consultation with the geo nodes people this
was deemed a passable solution, there was only a single call to this
method so performance wasn't a concern, so no special care had to be
taken to single out just the problematic MSVC versions.
If this bug pops up in other parts of our code where performance IS a
concern a more delicate approach may be required.
[1] https://developercommunity.visualstudio.com/t/10448291
Pull Request: https://projects.blender.org/blender/blender/pulls/112616
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.
