Now always check for a default unit, and evaluate the whole expression in this "unit space". Not an ideal solution, but should handle most cases nicely (we can't address all possible corner cases anyway).
Campbell Barton (campbellbarton)
- Maniphest Tasks
- T39267: Implement UnitTesting for UI Units handling, and improve it
T38722: Adding units in Imperial setting results in inconsistent values
- rBS8535b9bd1543: Fix T38722: Adding units in Imperial setting results in inconsistent values
rB8535b9bd1543: Fix T38722: Adding units in Imperial setting results in inconsistent values
rB47983ccec5ba: Fix T38722: Adding units in Imperial setting results in inconsistent values
Rather postpone this for 2.70. But looks like it could be a good fix too.
Should the addition of ')' to ch_is_op be added separately? looks like it may apply even without any of the other changes.
Talked to @Bastien Montagne (mont29),
This code is a little fragile and hard to guess how changes may impact other areas so proposed to...
- Write py api for units bpy.utils.units
- Collect a list of all expressions and their expected results. (even ones that currently fail)
- Write unit tests similar to source/tests/bl_pyapi_mathutils.py
Then review and apply patches, making sure they don't make breaking changes to existing functionality.
This isn't urgent and Im happy to do this too, but @Bastien Montagne (mont29) is interested to check on getting this setup.
Updated against latest master, tweaked a bit things, added a few test cases.
Basically, this patch will try to find a default unit in current system, either from given string,
given previous string, or fallback to system's default unit, and will use this default unit
for all items of the addition that do not have an explicit one.
When found, default unit is always the biggest one available.
In other words:
1+1" -> 2" 1+1"+2' -> 3'1"
This has the main benefit of keeping non-specified values in current unit system. Else,
typing 1+1" would give 1BU+1in, which is especially bad in imperial system...
Note: we could try to be even smarter, and infer 'implicit parenthesis' (as in 1+1"+2',
which would translate as (1+1)"+2'), but this would really complexify the code, and I
doubt we could always get expected result/behavior anyway, so imho better to force user
to use explicit parenthesis in those cases!
*picky*, With this I worry that it may be haphazard which unit is found...
Would rather have some logic here...
I sit corrected :), other minor feedback.
overall would really like to check this better though...
odd name. better call scale_pref_base / scale_pref_default ?
*picky*, previously this was isolated in its own block,
could move this into own static func? unit_detect_from_str