The previous design is rather old and has a couple of problems:
* Scalability: The current solution of adding little icon buttons next to the
data-block name field doesn't scale well. It only works if there's a small
number of operations. We need to be able to place more items there for better
data-block management. Especially with the introduction of library overrides.
* Discoverability: It's not obvious what some of the icons do. They appear and
disappear, but it's not obvious why some are available at times and others
not.
* Unclear Status: Currently their library status (linked, indirectly linked,
broken link, library override) isn't really clear.
* Unusual behavior: Some of the icon buttons allow Shift or Ctrl clicking to
invoke alternative behaviors. This is not a usual pattern in Blender.
This patch does the following changes:
* Adds a menu to the right of the name button to access all kinds of operations
(create, delete, unlink, user management, library overrides, etc).
* Make good use of the "disabled hint" for tooltips, to explain why buttons are
disabled. The UI team wants to establish this as a good practise.
* Use superimposed icons for duplicate and unlink, rather than extra buttons
(uses less space, looks less distracting and is a nice + consistent design
language).
* Remove fake user and user count button, they are available from the menu now.
* Support tooltips for superimposed icons (committed mouse hover feedback to
master already).
* Slightly increase size of the name button - it was already a bit small
before, and the move from real buttons to superimposed icons reduces usable
space for the name itself.
* More clearly differentiate between duplicate and creating a new data-block.
The latter is only available in the menu.
* Display library status icon on the left (linked, missing library, overridden,
asset)
* Disables "Make Single User" button - in review we weren't sure if there are
good use-cases for it, so better to see if we can remove it.
Note that I do expect some aspects of this design to change still. I think some
changes are problematic, but others disagreed. I will open a feedback thread on
devtalk to see what others think.
Differential Revision: https://developer.blender.org/D8554
Reviewed by: Bastien Montagne
Design discussed and agreed on with the UI team, also see T79959.
For the Asset Browser, it needs to be possible to drag assets into various
editors, which may not come from the current .blend file. In other words, the
dragging needs to work with just the asset metadata, without direct access to
the data-block itself.
Idea is simple: When dragging an asset, store the source file-path and
data-block name and when dropping, append the data-block. It uses existing drop
operators, but the function to get the dropped data-block is replaced with one
that returns the local data-block, or, in case of an external asset, appends
the data-block first.
The drop operators need to be adjusted to use this new function that respects
assets. With this patch it only works for dragging assets into the 3D view.
Note that I expect this to be a short-lived change. A refactor like D4071 is
needed to make the drag & drop system more future proof for assets and other
use cases.
Part of the first Asset Browser milestone. Check the #asset_browser_milestone_1
project milestone on developer.blender.org.
Differential Revision: https://developer.blender.org/D9721
Reviewed by: Bastien Montagne, Brecht Van Lommel
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
Layout block safety sizes were not scaled correctly with interface scale.
Differential Revision: https://developer.blender.org/D9569
Reviewed by Brecht Van Lommel
The logic for separator-spacers (used here for right-alignment) didn't take
region scaling into account. Usually that's not an issue because they are
otherwise only used in headers which can't zoom.
The overlap with the `Panel` flags that start with "PNL" was quite
confusing because wasn't clear which enum a flag was from. The
new names are a bit longer, but the clarity is worth it.
Re-enables support for menus to have items without identifier or name that can be used to separate sections.
Differential Revision: https://developer.blender.org/D9463
Reviewed by Hans Goudey
The current layout gave too little space for the full "Search" string inside
the button.
Fix this by making sure radio-buttons have their text center aligned by default
in pop-ups too, like they do anywhere else.
This does affect a few other cases, e.g. the "RGB"/"HSV"/"Hex" radio-toggles
for color pickers. But this should be fine, I don't think they were ever
intentionally using left-aligned text (while similar buttons outside of pop-ups
didn't).
The list of buttons in the button group needs to be updated to take into
account the old button inserted into the button list for the new block.
Differential Revision: https://developer.blender.org/D9428
This commit contains some improvements to this function to make this
function more purposeful and readable.
- Split updating information of the old button to a new function.
- Remove some 7 year old code disabled with `#if 0`.
- Add comments explaining some of the less obvious aspects.
Differential Revision: https://developer.blender.org/D9117
Menus with categories gain a dividing line and omit the title.
Differential Revision: https://developer.blender.org/D5135
Reviewed by Brecht Van Lommel
Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required.
Differential Revision: https://developer.blender.org/D9250
Reviewed by Campbell Barton
With all the work on DNA defaults for 2.91, it's nice to expose this
convenient operator. This was already hardcoded in the UI code to the
backspace key, adding it to the keymap instead will make the shortcut
automatically show in the button right click menu.
Differential Revision: https://developer.blender.org/D9219
Changing the color of monochrome alert icons would not change until the theme was reloaded.
Differential Revision: https://developer.blender.org/D9062
Reviewed by Harley Acheson
Change to monochrome version of the large alert icons and use 'Question' for the the Quit Confirm dialog box.
Differential Revision: https://developer.blender.org/D9062
Reviewed by Pablo Vazquez
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.
Now versioning UserDef is run in readfile.c,
as is done for other Blender data.
Previously versioning was mixed with other run-time initialization,
so it needed to be called later by the window manager.
Version patching userpref.blend wasn't using the correct version,
causing settings not to be properly updated.
This seems the likely cause of T70196 and similar bugs.
Where the if statement was just a check for an error or an unhandled
condition and there are no else statements, the rest of the function
doesn't need to be indented.
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.
It's generally considered a better codestyle to check conditions early
and exit early when they are not met, over having most logic of a
function within a big `if`-block. Otherwise people have to go over the
entire block to see if there's possibly an `else` somewhere, or any
followup logic.
There's the old and ugly hack where the `uiBut.poin` points to the
button itself. When reallocating the button we have to update that
pointer of course.
The function this was in already checks the conditions under which it
can operate (as it should). No need to force the caller to do these
(quite specific) checks, the function can just do nothing if the button
doesn't need these operations.
Otherwise we'd have to always execute these checks before calling, which
makes calling it a hassle, makes the code harder to follow and generally
harder to maintain (what if the conditions change?).
E.g. the 'x' icons or eyedropper icons in text buttons. They didn't use
to have any mouse over feedback, now we dim the icon until hovered.
This kind of feedback helps users see that the icons are interactive,
and if they are within their interaction hotspot.
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
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
Blender does string based searching in many different places.
This patch updates four of these places to use the new string
search api in `BLI_string_search.h`.
In the future we probably want to update the other searches as well.
Reviewers: Severin, pablovazquez
Differential Revision: https://developer.blender.org/D8825
-1 is a valid value to pass as RNA float precision. We let the UI code
figure out an appropriate precision then. So don't fail the assert if
-1 is passed.
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).
This was reported for the "Add Node" search functionality, but is
relevant in other searches as well.
So e.g. when searching for "Separate XYZ", typing "sep", then " " (with
the intention to type "X" next) would clear the search field. Now use
the same method (matching against all search words) as in F3 searching
('menu_search_update_fn') in other searches as well [searching IDs,
property objects, finding nodes,...]
This should give a much nicer search experience in general.
Note: this does not touch other searches in the Dopesheet, Outliner,
Filebrowser or User Preferences that have other search implementations.
Maniphest Tasks: T78084
Differential Revision: https://developer.blender.org/D8232
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.
