Caused by {rB278011e44d43}.
Framebuffer management since above commit now seems to require region
bind/unbind in for the operator to be able to redraw correctly without
using the same framebuffer in multiple contexts.
Maniphest Tasks: T87771
Differential Revision: https://developer.blender.org/D11084
While the existing behavior worked as intended,
it wasn't possible to have two views on the same file at different
locations.
Since there isn't much use in having two views open at the same location
allow one view to be at a different scroll location.
UI edit-source and selecting a text data block now need explicit calls
to scroll to the cursor location.
Resolves T87284
E.g. steps to reproduce:
* Enter Vertex Paint mode
* In the tool settings, right-click > "Edit Source"
When creating a number slider via `layout.prop(..., slider=True)`, the UI code
would reallocate the number button to be a number-slider button. That's because
we now actually have different button data-structures for these (see
e6f0b60c2e). The edit source code stored data based on the button pointers,
which didn't get updated after changing the type. The fix just adds this
updating.
Partially reverts 2250b5cefe.
Removing the user count and fake user count icons was controversial (which was
expected) and there are a few further changes needed, that won't make it in
time for the release, see D9946.
While there is a design to bring back the user count and fake user indicators,
a new design idea was proposed that the UI team wants to follow. This came too
late for the 2.92 release, the new design is targeted at the 2.93 release now.
Meanwhile, UI team decision was to simply revert the design changes.
The new design is being worked on in https://developer.blender.org/T84669.
Note that this commit does not revert some internal changes done in
2250b5cefe. Namely the introduction of `ed_util_ops.c` and data-block
operators in there. These will still be needed in the new design.
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.
I only skipped a few loops in the monstrous ui_handle_menu_event
function. Also, I only changed variable names where necessary to
prevent redeclarations.
Differential Revision: https://developer.blender.org/D8586
The current on-size-fits-all `uiBut` creates quite a mess, where it's
hard to reason about which members are free for use, under which
conditions they are used and how.
`uiBut` also has members that aren't used at times, violating the "don't
pay for what you don't use" principle.
To address this, we want to move to typed buttons, where `uiBut` is just
a base struct and each type extends it as needed. That structures data
better and type specific data is only available if it's actually used by
a button type.
Two trade-offs:
* Many casts to the derived type have to be done.
* Sometimes we change the button type after it's created. So I had to
add logic to reallocate the button for use with the new, possibly
derived struct. Ideally that wouldn't be needed, but for now that's
what we have.
Part of T74432.
Differential Revision: https://developer.blender.org/D7610
Reviewed by: Brecht Van Lommel, Campbell Barton
Small tweaks to make labels and texts more correct, consistent and
polished.
Reviewed by: Aaron Carlisle, Julian Eisel
Differential Revision: https://developer.blender.org/D8346
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/editors/interface` module.
No functional changes.
Note that this code is rather rough and slightly hacky, a proper
solution needs to be designed at some point probably, but for now this
should work fine.
As usual, master collections and root node trees remain TODO for now.
In this case giving `CTX_wm_menu()` priority over `CTX_wm_region()` is all
that's needed and makes sense (since we want exactly the hovered button, not
some other active button in the region/menu hierarchy).
The situation with pop-ups is still tricky, see T73565. But as a first step
it's probably good to let functions be more explicit about what they want when
querying UI context. So I added a variation of a UI-context function for cases
like this.
Follow up of b2ee1770d4 and 10c2254d41, part of T74432.
Now the area and region naming conventions should be less confusing.
Mostly a careful batch rename but had to do few smaller fixes.
Also ran clang-format on affected files.
strips
This uses the new "selected_nla_strips" context member in
UI_context_copy_to_selected_list().
bonus: this also makes the "Copy To Selected" button operator [in the
button context menu] work for anything NLA Strip related.
Maniphest Tasks: T66494
Differential Revision: https://developer.blender.org/D7281
The old convention was easy to confuse with ScrArea.
Part of https://developer.blender.org/T74432.
This is mostly a batch rename with some manual fixing. Only single word
variable names are changed, no prefixed/suffixed names.
Brecht van Lommel and Campbell Barton both gave me a green light for
this convention change.
Also ran clan clang format on affected files.
Part of https://developer.blender.org/T74429.
There's a chance that this causes some issues becaue in some cases we
change from getting the window from context to getting it from somewhere
else.
not work for unlocking
Special case for when we do this on "lock":
- locked sequences are not in "selected_editable_sequences"
- use "selected_sequences" in that case
Maniphest Tasks: T74434
Differential Revision: https://developer.blender.org/D7023
bone constraints settings
'UI_context_copy_to_selected_list()' was working fine for constraints on
objects (would properly get the path and list of selected objects) and
also for bone settings (would properly get the path and list of bones).
There was no special case for constraints on bones though, so code would
work on selected objects (not selected bones).
So we now get the right bones and resolve the path to the constraint
setting _from the bones_.
Maniphest Tasks: T74006
Differential Revision: https://developer.blender.org/D6897
This patch contains the work that I did during my week at the Code Quest - adding support for tiled images to Blender.
With this patch, images now contain a list of tiles. By default, this just contains one tile, but if the source type is set to Tiled, the user can add additional tiles. When acquiring an ImBuf, the tile to be loaded is specified in the ImageUser.
Therefore, code that is not yet aware of tiles will just access the default tile as usual.
The filenames of the additional tiles are derived from the original filename according to the UDIM naming scheme - the filename contains an index that is calculated as (1001 + 10*<y coordinate of the tile> + <x coordinate of the tile>), where the x coordinate never goes above 9.
Internally, the various tiles are stored in a cache just like sequences. When acquired for the first time, the code will try to load the corresponding file from disk. Alternatively, a new operator can be used to initialize the tile similar to the New Image operator.
The following features are supported so far:
- Automatic detection and loading of all tiles when opening the first tile (1001)
- Saving all tiles
- Adding and removing tiles
- Filling tiles with generated images
- Drawing all tiles in the Image Editor
- Viewing a tiled grid even if no image is selected
- Rendering tiled images in Eevee
- Rendering tiled images in Cycles (in SVM mode)
- Automatically skipping loading of unused tiles in Cycles
- 2D texture painting (also across tiles)
- 3D texture painting (also across tiles, only limitation: individual faces can not cross tile borders)
- Assigning custom labels to individual tiles (drawn in the Image Editor instead of the ID)
- Different resolutions between tiles
There still are some missing features that will be added later (see T72390):
- Workbench engine support
- Packing/Unpacking support
- Baking support
- Cycles OSL support
- many other Blender features that rely on images
Thanks to Brecht for the review and to all who tested the intermediate versions!
Differential Revision: https://developer.blender.org/D3509
Rigify uses a property group to contain options of its rigs, so
currently it is impossible to use Alt-Click or Copy To Selected
to change a setting for multiple rigs at the same time.
The main problem here is that there is no efficient way to find
which bone the property group belongs to. To maintain performance,
implement this by checking the active bone if it is known. Copy
Data Path and related features still don't work, as data path
calculation can't use context.
Differential Revision: https://developer.blender.org/D6264
This patch is only for the eyedropper to create materials.
Options:
Click: Create Stroke Material
Shift+Click: Create Fill Material.
Shift+Ctrl+Click: Create Stroke and Fill Material.
Toolbar:
{F7718606}
Reviewed By: brecht, mendio
Differential Revision: https://developer.blender.org/D5688
Without this patch there could only be one superimposed icon
and the operators were hard coded for the button types.
This keeps the previous, sort of predefined extra icons working in a
rather generic way, but allows adding specific ones for specific case
through `UI_but_extra_operator_icon_set()`.
Reviewed by: Campbell Barton
Differential Revision: https://developer.blender.org/D5730
NodeTree structures of materials and some other data blocks are
effectively node group datablock objects that are contained inside
the parent block. Thus, direct references to them are only valid
while blender is running, and are lost on save.
Fix Copy As New Driver to create a reference that goes through
the owner datablock, by adding a new ID flag to mark private
pseudo-datablocks.
Also fix functions that return full paths to structures and
properties, e.g. used in python tooltips. Functions for paths
from ID to struct or property can't be changed because of
Animation Data related code.
Reviewers: mont29
Differential Revision: https://developer.blender.org/D5559
In case the property is a RNA pointer, `RNA_path_resolve()` will try to
resolve it and return that pointer, instead of returning expected
container... That is a bad inconsistency in the rNA path API, but no
proper way to solve it for now...
The old layout of `PointerRNA` was confusing for historic reasons:
```
typedef struct PointerRNA {
struct {
void *data;
} id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
This patch updates it to:
```
typedef struct PointerRNA {
struct ID *owner_id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
Throughout the code base `id.data` was replaced with `owner_id`.
Furthermore, many explicit pointer type casts were added which
were implicit before. Some type casts to `ID *` were removed.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D5558
This reverts commits 54fd8176d7, 4c5becb6b1 and 8f578150e.
Those kind of commits must be reviewed and approved by project owners.
That one:
* Broke Collada building by not properly updating all calls to modified
function.
* Broke *whole* ID management by not properly updating library_query.c.
And in general, I am strongly against backward ID pointers, those are
*always* a serious PITA for ID management. Sometimes they cannot be
avoided, but in general other ways to get that kind of info should be
investigated first.
NodeTree structures of materials and some other data blocks are
effectively node group data block objects that are contained inside
the parent block. Thus, direct references to them are only valid
while blender is running, and are lost on save.
Fix Copy As New Driver to create a reference that goes through
the owner data block, by adding a new runtime field to bNodeTree.
