For the man rationale behind this design, see 49f088e2d0. Further,
this removes users of uiBut.a1/uiBut.a2, which is a very ugly design
choice (hard to reason about).
Note that I had to do rather ugly, specific exceptions for the number
buttons in `ui_def_but_rna()`. But once all users of a1/a2 are removed,
this special handling shouldn't be needed anymore.
I also had to move a sanity check out of the button definition. It's now
moved into a new debug only sanity checking function executed when
finishing the layout definition (block end).
- Declare variables where they are initialized
- Use consistent variable and static function names
- Use helper functions more for common operations
- Remove use of BezTriple struct, use CurveProfilePoint instead
- Apply small simplifications to code in some situations
Further changes to interface_handlers.c to avoid a block of variable
declarations at the beginning of functions. Also use const in some
situations. I only made changes where the variable's intended scope
was obvious.
- Reduce variables scope
- Use some const prefixes
- Initialize variables at declaration
- Use comparison to boolean false instead of 0
Differential Revision: https://developer.blender.org/D8678
I only skipped a few loops in the monstrous ui_handle_menu_event
function. Also, I only changed variable names where necessary to
prevent redeclarations.
Differential Revision: https://developer.blender.org/D8586
Changing line-width shouldn't scale cursor motion. Related to T79787.
Use dpi_fac for scaling curve error threshold & number button drag
threshold calculation.
For the main rationale behind this design, see 49f088e2d0. Further,
this removes users of uiBut.a1, which is a very ugly design
choice (hard to reason about).
Part of T74432.
For the main rationale behind this design, see 03b122e2a18df. Further,
this removes users of `uiBut.a1`/`uiBut.a2`, which is a very ugly design
choice (hard to reason about).
Part of Part of T74432.
The current on-size-fits-all `uiBut` creates quite a mess, where it's
hard to reason about which members are free for use, under which
conditions they are used and how.
`uiBut` also has members that aren't used at times, violating the "don't
pay for what you don't use" principle.
To address this, we want to move to typed buttons, where `uiBut` is just
a base struct and each type extends it as needed. That structures data
better and type specific data is only available if it's actually used by
a button type.
Two trade-offs:
* Many casts to the derived type have to be done.
* Sometimes we change the button type after it's created. So I had to
add logic to reallocate the button for use with the new, possibly
derived struct. Ideally that wouldn't be needed, but for now that's
what we have.
Part of T74432.
Differential Revision: https://developer.blender.org/D7610
Reviewed by: Brecht Van Lommel, Campbell Barton
The icons are label buttons. Usually these are not editable and can not
become active. These are draggable ones though (so dragging files can be
dragged by dragging the icon) which creates an exception to this rule.
So hovering the icon would activate its label and when executing the
rename operator via shortcut it wouldn't get exited properly. This broke
the invariant of only allowing a single active button at a time.
Added an assert to check that invariant now.
Letting the code to activate the text button ensure any currently active
button is exited seems sensible.
Disabled buttons would incorrectly toggle state when a drag toggle
passed over them. This adds a check to prevent a drag toggle on disabled
buttons.
Differential Revision: https://developer.blender.org/D8476
button
This was reported for the FCurve modifier restrict ranges, but might fail
elsewhere, too. Reason is that the post_but has its range (hardmin/
hardmax etc) set before the updates to the active button take place, so
changes here dont end up on the post_but (even though the RNA range
function is properly called for a new defined button - new one is not the
same as the post_but though).
Now update the ranges on the post_but when that gets active.
Fixes T78763
Maniphest Tasks: T78763
Differential Revision: https://developer.blender.org/D8265
Use 'emboss' instead of 'draw_type' as enum, layout & functions use
the term emboss.
This issue was noted by @Poulpator in D8414, as `dt` is also an
abbreviation for delta-time.
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/editors/interface` module.
No functional changes.
Under the hood the CurveProfile widget (used for bevel custom profiles)
uses a bezier curve, but right now though it only supports two of the
bezier curve handle types, vector and auto. This patch adds support for
free handles and adds all of the logic for editing them.
This is the first step to the ability to import and export curve objects
in the widget.
There's some code cleanup in curveprofile.c. Movement for handles and
control points is abstracted to functions there rather than happening
in interface_handlers.c.
An "Apply Preset" button is also added, which solves a confusing issue
where you apply a preset, then change the number of samples and the
preset doesn't change. The button makes it clear that the preset needs
to be reapplied.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D6470
E.g. simply on button hover changes, the tree would be needlessly rebuilt.
I wouldn't be surprised if this causes side-effects, for some state changes we
may still have to do a full rebuild.
When using CTRL wheel mouse the items were selected in a different order than when opening the menu and use the wheel mouse.
Reviewed By: Brecht van Lommel
Differential Revision: https://developer.blender.org/D7791
Pressing 'E' over a number button to pick a distance was keeping
left-right arrows instead of using the eye-dropper cursor.
Workaround this by clearing the active button before setting the cursor.
Making this work reliably on the event system side is difficult. So
instead, let the toggle icons take and swallow double-click events on
the UI handler level.
The second change in this patch seems to be only needed for touchpads.
Without it, renaming would still be triggered sometimes, because the
hovered button wasn't re-activated fast enough.
