| Age | Commit message (Collapse) | Author |
|---|
|
The activation of the text button is a bit special, since it happens during
drawing, the layout isn't computed yet then. Comparable cases where the button
is added on top don't use the layout system, so this didn't become an issue
until now. Trigger a delayed call to `UI_but_ensure_in_view()`.
|
|
Ref T92709
|
|
Adds a `wmOperatorCallContext` typedef for the existing `WM_OP_XXX`
operator context enum. This adds type safety, allows the compiler to
produce better warnings and helps understanding what a variable is for.
Differential Revision: https://developer.blender.org/D13113
Reviewed by: Campbell Barton
|
|
Also fix several wrong usages of `IFACE_` (as a reminder, error/info
messages should use `TIP_`, not `IFACE_`).
|
|
While c7d94a7827a5be9343eea22a9638bb059f185206 exposed this bug,
this was caused by text widths being calculated without taking the zoom
level into account since drawing at a smaller size is often wider than
the width of the larger text scaled by the zoom.
|
|
If a renaming button was removed via `UI_but_active_only_ex()` and that
button was placed using the layout system, the button was still in the
layout.
So far this didn't cause issues, because all cases where the button may
be removed were not using the layout system.
|
|
Color buttons were drawing single icon width.
|
|
Icon only popup buttons needed to be adjusted too,
add an uiTextIconPadFactor.icon_only to support this.
|
|
Labels in headers reserved space for an icon even when no icon was used.
This is caused by the shared function ui_text_icon_width adding 1.5x
a buttons X-units width the the width of the string.
Menu buttons detected this and subtracted the extra padding.
Instead of adding the same workaround for labels,
add ui_text_icon_width_ex that takes a padding argument.
Add presets for 'default', 'compact' and 'none' to avoid duplicating
padding values.
This allows removal of hard-coded label scaling for the add-object tool.
|
|
Change KeyMapItem.alt/ctrl/shift/oskey to integer types,
where -1 is used to ignore the modifier when matching key-map items.
It was only possible to set all modifiers to -1 at once from RNA
using the 'any' property.
Afterwards individual modifiers could be set back to true/false.
Although these key-map items could not be exported/imported.
Exposing the values directly avoids the need for cumbersome workarounds.
|
|
|
|
|
|
Using `UILayout.menu()` [1] or `UILayout.menu_contents() [2], the menu
would just always be added, the `poll()` check not being executed. As
API user I would expect the `poll()` to deterimine visiblity of the
menu.
[1] https://docs.blender.org/api/current/bpy.types.UILayout.html#bpy.types.UILayout.menu
[2] https://docs.blender.org/api/current/bpy.types.UILayout.html#bpy.types.UILayout.menu_contents
Differential Revision: https://developer.blender.org/D12053
Reviewed by: Campbell Barton
|
|
|
|
|
|
Also use doxy style function reference `#` prefix chars when
referencing identifiers.
|
|
`UILayout.operator_menu_enum()` now returns the operator properties, just like
`UILayout.operator()`. This makes it possible to set options for the operator
displayed in the menu. In C it can be done through the new
`uiItemMenuEnumFullO()` or `uiItemMenuEnumFullO_ptr()`.
It's reasonable to have this, probably just a small thing never bothered to
add. D10912 could use it, the following comment can be addressed now too:
https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/space_nla/nla_buttons.c$583-586
|
|
Likely uncovered by 6c97c7f767c9, the actual mistake would be from
6942dd9f4900.
The hacks to display text buttons for renaming in UI-Lists used the emboss of
the text button for handling logic. It relied on the emboss `NONE` but we also
introduced `NONE_OR_STATUS` with 6942dd9f4900. Both values need to be treated
equally for the logic of this hack to work.
The change in `interface_layout.c` is actually not needed for this exact issue,
but it's the correct thing to do. There may actually be more cases where `NONE`
and `NONE_OR_STATUS` need to be treated equally. Something to be checked still.
|
|
Passing `emboss=False`set `UI_EMBOSS_NONE` in the layout, which
completely disables button background colors for things like animation
state. This commit changes that to `UI_EMBOSS_NONE_OR_STATUS`,
which effectively restores the behavior to what it was prior to the
addition of that flag, with the added option to completely disable
the status emboss with `UI_EMBOSS_NONE`.
|
|
|
|
|
|
|
|
This patch adds domain and data type information to each row of the
attribute search menu. The data type is displayed on the right, just
like how the list is exposed for the existing point cloud and hair
attribute panels. The domain is exposed on the left like the menu
hierarchy from menu search.
For the implementation, the attribute hint information is stored as a
set instead of a multi-value map so that every item (which we need to
point to descretely in the search process) contains the necessary data
type and domain information by itself. We also need to allocate a new
struct for every button, which requires a change to allow passing a
newly allocated argument to search buttons.
Note that the search does't yet handle the case where there are two
attributes with the same name but different domains or data types in
the input geometry set. That will be handled as a separate improvement.
Differential Revision: https://developer.blender.org/D10623
|
|
|
|
This commit adds support for `bl_description` and python docstrings for panels.
This is useful for pop-over panel types so they can have a label and description.
This commit also includes an example use case.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D10429
|
|
|
|
|
|
Previously both `char` and `int` were used to represent this enum.
Differential Revision: https://developer.blender.org/D9903
|
|
Also decrease scope of some variable declarations.
|
|
|
|
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
|
|
Improved alignment of labels with other buttons.
Differential Revision: https://developer.blender.org/D9058
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 a4aa94c41cb7. 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.
|
|
An error adding search to an existing button,
caused by my own error in rBa4aa94c41cb79e9.
|
