This is similar to c4a2067130130d, but applies to the general UI and is only
about single data-blocks. Here there was a similar problem: How can buttons
pass the data they represent to operators? We currently resort to ugly ad-hoc
solutions like `UI_context_active_but_get_tab_ID()`. So the operator would need
to know that it is executed on a tab button that represents a data-block.
A single button can now hand operators a data-block to operate on. The operator
can request it via the "id" context member (`CTX_data_pointer_get_type(C, "id",
&RNA_ID)` in C, `bpy.context.id` in .py).
In this commit, it is already set in the following places:
* Generic RNA button code sets it to the pointed to data-block, if the button
represents a data-block RNA pointer property. (I.e for general data-block
search buttons.)
* Data-block selectors (`templateID`) set it to the currently active data-block.
* The material slot UI-List sets it for each slot to the material it represents.
The button context menu code is modified so its operators use the context set
for the layout of its parent button (i.e. `layout.context_pointer_set()`).
No user visible changes. This new design isn't actually used yet. It will be
soon for asset operators.
Reviewed as part of https://developer.blender.org/D9717.
Reviewed by: Brecht Van Lommel
Shared helper function to create a split layout with an alert icon for popup dialogs.
Differential Revision: https://developer.blender.org/D9486
Reviewed by Julian Eisel
Panels for active uiBlocks always have a type, because the process that
makes them uses the types. Add an assert just to make it clear that the
assumption is purposeful.
After recent changes to the context panel layout (rB187cc5e26d28b1a8),
there has been an error printed when running propery search:
> Error: separator_spacer() not supported in popups.
The layout code thinks it's drawing in a menu because region->visible
isn't properly set for the other tab searches. This patch sets that field
for the temporary searching region, but it also disables searching in the
context breadcrumbs panel, because at best this will just give results
for the names of the active object, etc. This isn't helpful since
those labels are mostly in every tab anyway.
Differential Revision: https://developer.blender.org/D9425
Allow project to build without definition of optional UI_PROP_DECORATE.
Differential Revision: https://developer.blender.org/D8370
Reviewed by Julian Eisel
Menus with categories gain a dividing line and omit the title.
Differential Revision: https://developer.blender.org/D5135
Reviewed by Brecht Van Lommel
This patch enables property search for all tabs in the property editor.
To make interaction faster, if the editor's current tab doesn't have a
result, the current tab changes to the next tab that has a match.
This patch implements basic code that only searches panels.
While we could run the existing "single tab" property search for every
tab, that would also do everything else related to the layout pass,
which would be less efficient, and maybe more complicated to maintain.
The search match status for every current tab of the property editor is
stored in a runtime bitfield and them displayed later by dimming icons
in the tab selector panel to the left. Using `BLI_bitmap` properly in
the runtime struct required moving it to `buttons_intern.h` and
adding a small API to access the search filter instead.
To make sure the editor isn't influenced by anything that happens while
building the layout for other tabs, most of the context is duplicated
and the new search is run in the duplicated editor.
Note that the tool settings tab works slightly different than the other
tabs, so I've disabled searching it for this commit. That would be a
relatively simple improvement, but would just require a bit of
refactoring of existing code.
Differential Revision: https://developer.blender.org/D8859
This adds arguments to `uiLayout.prop_tabs_enum` and the C equivalent
(`uiItemTabsEnumR_prop`) to gray out tabs based on a boolean array.
For property search in multiple tabs, we need a way to show which tabs
have a search result, but we still need to show which tab is active.
Differential Revision: https://developer.blender.org/D8858
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.
