| Age | Commit message (Collapse) | Author |
|---|
|
Ref T92709
|
|
|
|
Using the `uiButtonGroupFlag` type explicitly can avoid the need
to look up which enum should be used as an argument.
|
|
This function for replacing a button pointer in button groups is
needed by the block update from old code, so it cannot be removed
like its layout equivalent.
|
|
Even after the last commit to fix this assert, it still fails in the
case where a button was added before there was a button group
added to the block. Another fix for this would be to always create
a button group in UI_block_begin, but this assert has no particular
purpose, so it's simpler to just remove it.
|
|
When there was an active button in the "old" block from the last redraw,
this code tried to replace its pointer in the new block's button groups.
But in cases like the outliner or file browser, there are no groups
because the block doesn't use the layout system at all. This commit
just tweaks the assert to check whether there are any button groups.
|
|
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
|
|
This makes it unecessary to create a button group when the block
is created, giving more flexibility when creating the first group-- for
example, creating the first button group with special parameters.
|
|
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.
|
