mimics the previous behavior when settings were shared by both modes (but not equivalent).
NOTE: Due to the use of additional sRGB conversion in the LGG mode the result is not entirely accurate, this should perhaps be fixed.
Settings for each mode are kept in their own color values nevertheless, this avoids potential problems with float precision.
It wasn't enabled in snapping code from the beginning it seems,
but from quick tests snapping for mballs works just fine.
Maybe we could drop out check for edit object type now?
This means that if you have WITH_BF_QUICKTIME or WITH_CODEC_QUICKTIME enabled,
it will always use QTKit.
The old backend was only used on 32 bit OS X builds, now 32 and 64 bit builds will
give consistent input/output. On Windows or Linux quicktime isn't being used.
* deselect all no longer leaves an active point
* the most recently added spline becomes the active one
* on successful duplicate/delete the active point and active spline are reset
* Remove unused UI code for Info Space items. Was lying around here for some months already.
Probably we have to re-think the whole placement of the operator history thing, but thats for later. In the current config there is no room for these buttons though.
* Remove "FCurve/Driver Version fix" from help menu, was used for RNA changes during 2.5x.
* Keep utility code in animsys_refactor.py, might still become useful according to Joshua.
Frame change hotkeys now work in the following places:
1) Outliner - Main region
2) Action/NLA Editors - Channels Region
3) Info View - Reports region
Other places identified by the bugreport (but which I've decided to leave
alone):
- Text Editor (when no file open) - The way the keymaps work here means that
this can't be done without affecting normal text editing
- File Browser - What's the point of changing frames when you're about to
open/save the file?
- User Prefs - Is there any real point here either? Also, this is usually shown
in a separate window.
has been adjusted
Previously, the RNA settings tried to strictly enforce the constraint that the
start frame must be less than the end frame. However, this behaviour was
problematic, as it meant that you had to firstly move the end frame to its new
(higher) value, before moving the start frame. The same also applied in the
opposite direction.
Now, this behaves in the same way that the scene start/end buttons work: if the
new start frame is past the end frame, the end frame is "pushed" along to be the
same value as the start frame. The same applies in the opposite direction.
