Auto View automatically adjusts the view based on selection, so that the view is
always focused on the current selection.
A checkbox in the header is used to access it and it works for the following
selection methods: Toggle All, Border, Circle, Lasso, Left, Right, More, Less,
Linked, Column (so all except of single selection, in which this can be a bit
annoying)
Reviewed by @Aligorith (thanks for that :) )
and graph editor.
This was a tricky commit that was not so straightforward to make work.
The information for bones is not easy to come by in the animation curves,
however we do have some string manipulation tricks to make it happen.
Testing in gooseberry worked for the rigs there, commiting to master now
In the process, I've removed the old operator (ANIM_OT_channels_visibility_set)
and folded that option in with the hide operator, to make this consistent
with how this is done in the 3D view and other parts of Blender.
Now the hotkeys here work in line with what's done for other parts of Blender
* H = Hide selected
* Shift-H = Hide unselected (i.e. old VKEY behaviour)
* Alt-H = Reveal all
Revised the tools for managing which FCurves are visible in the Graph Editor
curves area. Now, there are the following tools in place:
* V (channels region only) = Hide all curves except those in selected channels [OLD]
* H = Hide all selected curves [NEW]
* Shift-H = Show all previously hidden curves [NEW]
I've removed the old operator to toggle visibility status of selected curves,
as it doesn't seem that useful anymore.
For FCurves where all the keyframes use the "simple" interpolation types
(i.e. Constant, Linear, and Bezier), we now use the old FCurve drawing
code that was used prior to the Easing Equations changes. This should
be generally faster in general.
When the "High Quality Line Drawing" option (View menu) is disabled,
the sampling rate (i.e. the size of timesteps to use when sampling
the FCurve for drawing it in most cases now) is set to be quite low
(i.e. at 0.1 frame increments). This amounts to at most 10 sub-steps.
In one test file (with a wide window), this had the effect of improving
the performance by over 3x. It's still not as good as a sampling-free
approach, but for this functionality is still needed for FModifiers,
so it's better that we can optimise this.
Make the UI API more consistent and reduce confusion with some naming.
mainly:
- API function calls
- enum values
some internal static functions have been left for now
Quick fix, this is actually a demonstration of why we should use modal keymaps!
We can give any event to *start* the op, but then hard-code how to *end* it... tsk.
This uses a different operator than the other time editors (as it needs to support
the setting of the value-cursor too), so the changes here didn't get propagated through.
Editing the y-coordinate of the right handle of a keyframe via the Active Keyframe
panel in the Graph Editor, while both handles are selected and are both of type "aligned"
resulted in weird behaviours such as the x-coordinate of the right handle changing
(and rapidly starting to overshoot) but nothing else. However, this problem
doesn't occur when only a single handle is selected.
It turns out that the "order of computation" logic in calchandleNurb_intern() gets
confused in the case of both handles being selected, and results in a sub-optimal
handling of the right handle being the one that's been changed. We hack around this
here by temporarily making it so that just the right handle is selected when doing
the updates here.
When the dopesheet was open, "keyframe edited" events from the graph editor
(i.e. fired whenever any properties on keyframes or FModifiers are changed)
would trigger the dopesheet to synchronise selection states of anim channels
and ensure that FCurve autocolours are initialised correctly.
This however was undesired when editing properties in the graph editor. Now,
made it so that keyframe adding/removing operators use different notifier flags
to specify that the channels might have changed + need colour syncing, and
adjusted the dopesheet updating logic to fit
Problem was introduced back in 2.70 during Project Pampa when the FCurve Normalisation
feature was introduced. The cause was that the normalised cursor value was always getting
passed to the KeyframeEditData context, even when it wasn't needed.
View2D had some inconsistencies making it error prone in some cases.
- Inconstant checking for NULL x/y args.
Disallow NULL args for x/y destination pointers, instead add:
- UI_view2d_region_to_view_x/y
- UI_view2d_view_to_region_x/y
- '_no_clip' suffix wasn't always used for non-clipping conversion,
switch it around and use a '_clip' suffix for all funcs that clip.
- UI_view2d_text_cache_add now clips before adding cache.
- '_clip' funcs return a bool to quickly check if its in the view.
- add conversion for rectangles, since this is a common task:
- UI_view2d_view_to_region_rcti
- UI_view2d_region_to_view_rctf
