- "Lines" in the sense of number of lines
- "Number" can mean "amount, count" or "index, offset"
- "Second" can be an ordinal number or a unit
- "Root": add the brush curve to the "square root falloff" sense
- "Strip" can be a sequence or a type of hair rendering
- "Constant" in the sense of a value, for the Geometry Nodes add
submenu (#105447).
Additionally, extract:
- "Press a key" from the Keymap preferences.
- "MaskLayer", upon new mask layer creation
Ref #43295, #105447
This reverts commit 19222627c6.
Something went wrong here, seems like this commit merged the main branch
into the release branch, which should never be done.
This reverts commit 68181c2560.
I merged 3.6 into 3.5 by mistake. Basically I had a PR against main,
then changed it in the last minute to be against 3.5 via the
web-interface unaware that I shouldn't do it without updating the
patch.
Original Pull Request: #104889
Note that the node group has its sockets names
translated, while the built-in nodes don't.
So we need to use data_ for the built-in nodes names,
and the sockets of the created node groups.
Pull Request #104889
Since the menu doesn't automatically align the labels like other menus
and pulldowns in Blender, I manually made them align using the blank
icon. However the menu button would also include this blank icon now.
This is a specific fix for the 3.5 release. In the main branch I will
replace it with proper support for automatically aligning labels in such
menus.
Own mistake in d204830107.
For some buttons the type is changed after construction, which means the button
has to be reconstructed. For example number buttons can be turned into number
slider buttons this way. New code was unintentionally overriding the button
type after reconstruction with the old type again.
No user-visible changes expected.
Essentially, this makes it possible to use C++ types like `std::function`
inside `uiBut`. This has plenty of benefits, for example this should help
significantly reducing unsafe `void *` use (since a `std::function` can hold
arbitrary data while preserving types).
----
I wanted to use a non-trivially-constructible C++ type (`std::function`) inside
`uiBut`. But this would mean we can't use `MEM_cnew()` like allocation anymore.
Rather than writing worse code, allow non-trivial construction for `uiBut`.
Member-initializing all members is annoying since there are so many, but rather
safe than sorry. As we use more C++ types (e.g. convert callbacks to use
`std::function`), this should become less since they initialize properly on
default construction.
Also use proper C++ inheritance for `uiBut` subtypes, the old way to allocate
based on size isn't working anymore.
Differential Revision: https://developer.blender.org/D17164
Reviewed by: Hans Goudey
Tool settings can be accessed from both `tool_settings` &
`scene.tool_settings`.
As of [0] `scene.tool_settings` was used instead of `tool_settings`
causing the snap shortcut not to display.
Resolve by supporting variations of data-paths so both are detected.
[0]: 9a76dd2454
This simplifies some memory management, ammortizes some of the many
small allocations when building UI layouts, and simplifies the code
that deals with the groups. `uiBlock` is no longer a trivial type.
In my testing this saved a few ms when drawing a large node tree.
Duplicating context lists took a measurable amount of time when drawing
large node trees in the node editor. Instead of using a linked list of
entries, which results in many small allocations, use a vector. Also,
use std::string and StringRefNull instead of char buffers and pointers.
Adds the possibility of having a little number on top of icons.
At the moment this is used for:
* Outliner
* Node Editor bread-crumb
* Node Group node header
For the outliner there is almost no functional change. It is mostly a refactor
to handle the indicators as part of the icon shader instead of the outliner
draw code. (note that this was already recently changed in a5d3b648e3).
The difference is that now we use rounded border rectangle instead of
circles, and we can go up to 999 elements.
So for the outliner this shows the number of collapsed elements of a
certain type (e.g., mesh objects inside a collapsed collection).
For the node editors is being used to show the use count for the data-block.
This is important for the node editor, so users know whether the node-group
they are editing (or are about to edit) is used elsewhere. This is
particularly important when the Node Options are hidden, which is the
default for node groups appended from the asset libraries.
---
Note: This can be easily enabled for ID templates which can then be part
of T84669. It just need to call UI_but_icon_indicator_number_set in the
function template_add_button_search_menu.
---
Special thanks Clément Foucault for the help figuring out the shader,
Julian Eisel for the help navigating the UI code, and Pablo Vazquez for
the collaboration in this design solution.
For images showing the result check the Differential Revision.
Differential Revision: https://developer.blender.org/D16284
This is the conventional way of dealing with unused arguments in C++,
since it works on all compilers.
Regex find and replace: `UNUSED\((\w+)\)` -> `/*$1*/`
Currently node group assets are supported, but using them by dragging
from the asset browser is cumbersome. This patch adds all node group
assets from user asset libraries and the current file libraries to the
add node search menu and the link drag search menu.
Node groups added through the search will have their "options" hidden,
meaning the data-block selector is displayed. This helps keep the UI
clean, and the selector shouldn't be necessary anyway.
To make that possible, metadata like the node tree type and its inputs
and outputs has to be saved in the file. This requires re-saving the
files that contain the assets with the patch applied.
The node add search operator is moved from Python to C++ to ease
development and allow more flexibility. It supports a tooltip that
gives the description of assets.
Currently the node groups are added with the asset system's existing
"Append & Reuse" behavior. It's likely that linking should be possible
in the future too, but for now the idea is to use the more foolproof
option that doesn't create dependencies between files.
Because loading assets can potentially take a long time, the search
menu refreshes its items as new assets are loaded. However, changing
the search field is necessary to see the update.
Differential Revision: https://developer.blender.org/D15568
While missing the break before a default that only breaks isn't
an error, it means adding new cases needs to remember to add the
break for an existing case, changing the default case will also
result in an unintended fall-through.
Also avoid `default:;` and add an explicit break.
No user visible changes expected.
Merges the tree row and grid tile button types, which were mostly doing
the same things. The idea is that there is a button type for
highlighting, as well as supporting general view item features (e.g.
renaming, drag/drop, etc.). So instead there is a view item button type
now. Also ports view item features like renaming, custom context menus,
drag controllers and drop controllers to `ui::AbstractViewItem` (the new
base class for all view items).
This should be quite an improvement because:
- Merges code that was duplicated over view items.
- Mentioned features (renaming, drag & drop, ...) are much easier to
implement in new view types now. Most of it comes "for free".
- Further features will immediately become availalbe to all views (e.g.
selection).
- Simplifies APIs, there don't have to be functions for individual view
item types anymore.
- View item classes are split and thus less overwhelming visually.
- View item buttons now share all code (drawing, handling, etc.)
- We're soon running out of available button types, this commit merges
two into one.
I was hoping I could do this in multiple smaller commits, but things
were quite intertwined so that would've taken quite some effort.
Many menus get their labels exported to the .po file, but then are not actually translated in the UI.
Before:
{F13283752}
After:
{F13283750}
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15417
Part of T98560.
See https://wiki.blender.org/wiki/Source/Interface/Views
Adds all the basic functionality needed for grid views. They display
items in a grid of rows and columns, typically with a preview image and
a label underneath. Think of the main region in the Asset Browser.
Current features:
- Active item
- Notifier listening (also added this to the tree view)
- Performance: Skip adding buttons that are not scrolled into view
(solves performance problems for big asset libraries, for example).
- Custom item size
- Preview items (items that draw a preview with a label underneath)
- Margins between items scale so the entire region width is filled with
column, rather than leaving a big empty block at the right if there's
not enough space for another column (like the File and current Asset
Browser does it).
- "Data-View Item" theme colors. Not shown in the UI yet.
No user visible changes expected since the grid views aren't used for
anything yet.
This was developed as part of a rewrite of the Asset Browser UI
(`asset-browser-grid-view` branch), see T95653. There's no reason to
keep this part in a branch, continuing development in master makes
things easier.
Grid and tree views have a lot of very similar code, so I'm planning to
unify them to a degree. I kept things separate for the start to first
find out how much and what exactly makes sense to override.
Moves code for managing dragging data from buttons to a separate file.
This way all this closely related code is in one location, making it
easier to see how it all relates, and easier to find.
See previous commit for an explanation of what went wrong. Similar to
the fix there, we also have to update the dragged data (e.g. the
data-block) referenced by the button.
Committing separately since this could cause further issues.
In Blender buttons are recreated over redraws, except of the active
button which is kept alive, and replaces the new version of itself in
the new redraw. In order to do that, the button needs to be recognized.
This process of recognizing and matching buttons from different redraws
isn't always bullet-proof. That's okay-ish, but we have to make sure
that the relevant data of the old active button is updated with the
newest data.
Here the matching would go wrong, and the new active button was
recognized as the old active button, which was in fact removed when the
asset was cleared. This patch makes sure the image buffer attached to
the buttons is updated when buttons were recognized as matching.
Note that the dragging will still use the wrong data-block, this will be
fixed in the following commit.
Issue is that the operator acts on the active button, and also uses that in the
poll. So the actually active button would affect the poll of a different
button. For the superimposed icons we need to be able to execute these polls
properly for non-active buttons.
This enables temporarily overriding the active button for lookups via context.
While a bit of a hack it makes sense conceptually.
Reviewed By: Campbell Barton
Maniphest Tasks: T97518
Differential Revision: https://developer.blender.org/D14880
Issue is that the operator acts on the active button, and also uses that in the
poll. So the actually active button would affect the poll of a different
button. For the superimposed icons we need to be able to execute these polls
properly for non-active buttons.
This enables temporarily overriding the active button for lookups via context.
While a bit of a hack it makes sense conceptually.
Reviewed By: Campbell Barton
Maniphest Tasks: T97518
Differential Revision: https://developer.blender.org/D14880
`uiBut` contained a variable that was only used for these hot-key
buttons. This may also help getting rid of the `UI_BUT_IMMEDIATE` flag,
which is also only used for this button type. We are running out of
available bits for flags, so this would be useful.
Continuing the work from 49f088e2d0. Part of T74432.
This reverts the commits 8d9d5da137,
59cd616534 and
98a04ed452.
The commits are causing issues with MSVC, see D14926. I'm working on a
different solution, but that will need some work.
The code to compare buttons from the previous to the current frame, to
see if they match (an thus should keep the same state) was quite
generic, and didn't allow much flexibility/customization. For some
cases this isn't enough, and a more specific comparison is needed. Say
if some buttons don't actually store comparable data themselves, only
via the button context. This was the case in D14653.
It was possible to set context pointers for buttons via the layout, but
not for buttons in places where the layout system wasn't used (where
buttons are placed manually). This is needed for buttons in the
Outliner, see D14653.
