Reported by Pep Ribal
You can now select which snap point to remove (with Alt-A) by moving the cursor over them.
Display colors are also used to indicate which snap points are active, selected or just there.
One function converts bounding boxes to screen space, the other
converts a screen-space rectangle to 3D clipping planes.
Also const-ified some parameters in the ED_view3d API.
Reset only LANG variable to it's default value when setting locale to
short/long name failed and set LANGUAGE to value calculated from LANG
or value in user preferences (depending on if Default language is set)
so correct language ill be used for messages even if locale files aren't
generated.
Also disabled i18n prints in non-debug run so console wouldn't be polluted
by messages which aren't really informative for user now and might confuse.
now you can still use column access
previously...
mat[2] = 1, 2, 3
needed to be converted into...
mat[0][2] = 1
mat[1][2] = 2
mat[2][2] = 3
but with column access you can do...
mat.col[2] = 1, 2, 3
Having 'row' attribute is a bit redundant since direct indexing on a matrix uses row but included for completeness.
- rename 'bcycles' --> '_cycles', since this is the python convention when a py module uses a C module internally.
- use macros for returning None
- make with_osl an attribute rather then a function.
- changes methods METH_VARARGS --> METH_O when single args are used.
Problem was caused by trying to set locale to short named "es" locale
which failed. It's not really obvious which full locale name should
be used here (there are plenty of dialects), so rather than keeping
locale stuff on state when both of locale and utf-8 locale names
failed, restore default settings (restore environment variables and
use default locale for gettext).
This will resolve cases when spanish language is native on the system,
but it will fail in cases when somebody will want to have spanish
interface in non-spanish system. This might be worked around by setting
LANG and LANGUAGE environment variables to es_<dialect>.UTF-8 and it
should work fine,
This commit implements a way to define context of property which is used by
localization stuff and which is needed to resolve translation context when
some word wit the same english spelling is used in different meanings
(like Manual in meaning of tutorial, and Manual in meaning of something is
setting up by hand).
To define property's context there's a function RNA_def_property_translation_context.
If property doesn't have context, regular BLF_gettext function is used to get
translation of property name, otherwise BLF_pgettext is used for this.
Hence, for correct translation, messages in .po files should be marked
by "msgctxt" context, otherwise property with context declared wouldn't
be translated at all. Toolchain scripts from bf-translation project
would be updated soon.
If context for some values of enumerator property, property itself should
be moved to other context and all items from this enum would be moved to
this context automatically (it's impossible to move one few items to
another context).
P.S. Think context like "BRUSH" or "MODIFIER" are preferable than "NOUN" and "VERB"
because in some cases the same english noun used in different areas better be
translated differently to make translation more native.
Crash was caused by data segment corruption near "string" in view3d_modeselect_pup().
Enlarged size of this static buffer, so it's now enough to store translated modeselect string.
It's not actually fixes because in some other language this modeline might be much longer
and it'll lead to corruptions again.
note: if alpha is negative the code will still produce non-optimal results.
This is a separate issue though, the patch fix the premul assumption that
alpha can be zero and rgb still be valid.
this is a part of patch 29534, being applied separately
from patch [#29534] Change Matrix Representation and Access in Python to Conform with Standard Notation
by Andrew Hale (trumanblending)
Reformatted all lines longer than 120 characters in sculpt.c. Should
be no functional changes. Thanks to Campbell for pointing out the
issue.
I wouldn't normally do this, but just for reference, here is a
screenshot that hopefully makes clear why I think this is worth doing:
nicholasbishop.net/random/longlines00.png
* 1. Resize 4x4, code was ridiculously complex (cleanup only)
* 2. matrix * matrix checking for compatibility wasn't working right (bug in last release)
* 3. fix for result size for matrix * vector if matrix is 4x4 and vector size 3 (bug in recent patch)
* 4. fix for result size vector * matrix if matrix is 4x4 and vector size 3 (bug in recent patch)
