The buttons hide when the search finishes based on whether they are in
the "panel header" group. These buttons were not protected with a new
group. This adds a new group for operator button calls, and also makes
it so a new group is always created after the header buttons.
Uncovered by a4aa94c41c. Before that, it would actually be a possible `NULL`
pointer dereference.
It would happen if a `UILayout.prop()` was placed with the `full_event` option
set to `True` (or the C equivalent) for a non keymap-item property.
Now this the `full_event` option is ignored then with a warning print.
This commit makes the panel expansion set based on the search results
when the active tab in the properties editor changes. The multi-tab
search patch (D8859) actually doesn't handle this because it uses a
different code path.
This feature uncovered a subtle but fairly significant issue with the
implementation of property search (More details in T81113). Basically,
the search needed multiple redraws to properly display the expansion of
panels based on the search results. Because there is no animation of
panel expansion when switching tabs, the problem was exposed only now.
With this commit, hiding of "search only" buttons and panel size
calculation happens in a single final step of the panel layout pass.
The "search only" layout root flag is removed. Instead every button
inside a panel header is in a single "uiButtonGroup" marked with a
specific "in header" flag, an idea which could be generalized in the
future.
Differential Revision: https://developer.blender.org/D9006
We have our own assert implementation, `BLI_assert()` that is prefered over the
C standard library one. Its output is more consistent across compilers and
makes termination on assert failure optional (through `WITH_ASSERT_ABORT`).
In many places we'd include the C library header without ever accessing it.
For a future patch (D9006) we need these groups for longer than just the
the layout process, in order to differentiate buttons in panel headers.
It may also be helpful in the future to have a way to access related
buttons added in the same uiLayout.prop call. With this commit, the
groups are stored in and destructed with the uiBlock.
Currently there's no way to know if a button is inactive when it doesn't
match the search results, because they use the same 50% gray level.
This isn't a huge problem, but it could lead to confusion. This commit
uses a subtle solution, a 25% opacity when the button is inactive and
also filtered by search.
This requires flipping the meaning of the UI_SEARCH_FILTER_MATCHES
flag in the code, and also adding a widget_alpha_factor utility in
the widget code.
Differential Revision: https://developer.blender.org/D8975
Since the search is applied all in one phase, there is no need to store
a reference to the search filter in every uiBlock. Instead just pass it
as an argument to UI_block_apply_search_filter.
Setting the search match flag every time property search runs can
invalidate the results for panel headers. Instead, clear the flag on
every redraw and or the result of every search in the panel to it.
This adds a search bar to the properties editor. The full search for
every tab isn't included in this patch, but the interaction with
panels, searching behavior, UI, region level, and DNA changes are
included here.
The block-level search works by iterating over the block's button
groups and checking whether they match the search. If they do, they
are tagged with a flag, and the block's panel is tagged too. For
every update (text edit), the panel's expansion is set to whether
the panel has a result or not. The search also checks for matching
strings inside enums and in panel labels.
One complication to this that isn't immediately apparent is that
closed panel's subpanels have to be searched too. This adds some
complexity to the area-level panel layout code.
Possible Future Improvements:
- Use the new fuzzy search in BLI
- Reset panels to their expansion before the search started if
the user escape out of the text box.
- Open all child panels of a panel with expansion.
Differential Revision: https://developer.blender.org/D8856
This is needed for property search (upcoming patch D8856) where a
buttons labels are often separate buttons, but we need to highlight
the label to show that a property is a search result. This is
especially important in "property split" layouts where the label is
almost always another button in a separate column.
The button groups here are basically a flattened view of the buttons
in the layout tree. Every function that adds a new set of buttons
creates a new button group, and the new buttons are automatically
added to the most recent group. Then, each group is searched
separately in the property search phase. It's important that every
function adding a new button set calls layout_root_new_button_group.
Note that this won't be disabled when property search isn't active.
It may be useful for other things in the future, and trying to pass
that information to layout functions didn't feel worth it to me.
Differential Revision: https://developer.blender.org/D8783
Add an option to only draw icons for operator_enum menus. This is used
for drawing inline icon buttons in the outliner context menu for
collection color tagging.
Part of T77408
Differential Revision: https://developer.blender.org/D8880
This adds support for drawing icon buttons as a row in menus. This is
needed for drawing collection color tagging icons in the outliner
context menu in T77777.
Part of T77408
Differential Revision: https://developer.blender.org/D8317
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).
We do this in a couple of places, so it's worth having the logic wrapped
into a function.
Also, the only way to set the disabled hint for a button from outside of
`interface/` was through `UI_block_lock_set()`/`UI_block_lock_clear()`,
for which the usage isn't obvious when you just try to disable a single
button.
- Use WM_operatortype_description to get the operator description.
- Pass properties to WM_operatortype_name,
so the operator name callback is used.
- Add UI_but_operatortype_get_from_enum_menu function
to access the operator from enum menus.
- Change WM_operatortype_description to return NULL when there is no
description, use WM_operatortype_description_or_name
when either can be used.
Steps to reproduce were:
* Open Sequencer, add a sound strip
* In the sidebar, open the Adjust > Sound sub-panel
* Note the placement of the "Mono" item
The layout code would disable decorators if a property came from a
non-animatable data-block type. Doing so would mess up the alignment
where properties from different data-block types were be mixed.
This is not the case any more.
Note that when actually adding the decorator, a blank icon is inserted
to keep the alignment intact when the data-block type isn't animatable.
So the decorator is still not shown, but the alignment looks fine.
This may affect more cases. If so, and if that's an issue, the
decorators should be explicitly disabled.
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
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
ad4928a171 disabled alignment for too many cases. Still try to avoid
aligning many items, to avoid thousands of redundant alignment
calculations. But now we're much more picky adding an sub-row with
alignment.
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.
There was a weird looking gap between the checkbox and the "Motion Tracking"
label. Plus, the label could not be clicked to change the value, unlike
usually.
Issue is that the row is actually a sub-panel header. The checkbox being drawn
with the draw_header() callback, and the label being added as separate item by
the popover panel code. This adds a hack so the checkbox can add the panel
label itself (the popup drawing skips adding the label then). That addresses
mentioned issues.
Key-map display was doing thousands of redundant alignment operations.
Set the spacing instead as align was only set to use zero spacing.
This would have prevented the crash reported by T78636.
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/editors/interface` module.
No functional changes.
The shortcuts act on the modifier with its panel under the mouse.
The following shortcuts are enabled by default:
- Remove modifier: X, Delete
- Apply modifier: Ctrl A
- Duplicate modifier: Shift D
More shortcuts can be added in the keymap.
Each panel can now store a custom data RNA pointer, and a new
function is added to get the custom data for the panel under the
cursor. This custom data could be used to refactor the "List Panel
System" to generalize it and integrate it further with RNA.
The same functionality will be added in further commits where it
applies to constraints, grease pencil modifiers, and effects.
Differential Revision: https://developer.blender.org/D8031
Also, remove manually placed decorator for vertex groups in modifiers. This was
only needed because of this bug, and the layout was slightly misaligned.
Adds a wrapper-struct to create and return the three layouts required
for the propery split layout (i.e. `UILayout.use_property_split`). This
gives more flexibility for special treatment.
E.g. needed for adding the arrow icon buttons when there is a hierarchy
of nodes to be represented in the material properties (needs inserting
in the text column to not offset the split layout).
This commit also makes use of the utility for
`uiItemL_respect_property_split()`.
Usually items without labels don't use the property split layout and
just use the full layout width. In some cases that is not wanted because
it looks odd if single items within the split layout use the full width.
The option is unused but would be needed for adding decorators to the
material properties.
Previously `UILayout.prop_decorator()` (or `uiItemDecoratorR()` in C)
only worked for single items, not for arrays. The decorators are added
vertically, like `UILayout.prop()` adds them.
This will be needed for adding decorators to material properties, but
will likely have other use-cases as well.
Also, `None` (or `NULL`) can be passed for the data-pointer and property
now to create blank decorators (as already possible for
`uiItemDecoratorR_prop` in C).
