We need to be careful about not just looking up active tool data from
context, because this code path may also be run from the Properties,
which use the tools of the 3D view. So make sure related code falls back
to the 3D view, like it's already done in some other places.
NOTE: This also required some changes to Cycles code itself, who is now
directly including `BKE_image.hh` instead of declaring a few prototypes
of these functions in its `blender/utils.h` header (due to C++ functions
names mangling, this was not working anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/130174
- Modifications for marker selection to use the same behavior as
key selection in the dopesheet.
- Animation editors now mask out events for the timeline (when there are markers).
- Resolve logical conflicts with the Dope sheet keymap.
- Add Shift Drag & Ctrl Drag for box select & de-select.
Pull Request: https://projects.blender.org/blender/blender/pulls/129841
These have been removed since 4.0, this is not a pertinent information
to single out anymore.
Also downgrade report about missing obdata to `WARNING`, `ERROR` is a
bit strong for this.
This reverts commit 0a70360eb6. That's
because it caused issue #129366 which is much more serious, and the
cause is not obvious so far. Another fix will be submitted for the
original issue.
For C/C++ doc-strings should be located in headers,
move function comments into the headers, in some cases merging
with existing doc-strings, in other cases, moving implementation
notes into the function body.
This reverts commit 0a70360eb6. That's
because it caused issue #129366 which is much more serious, and the
cause is not obvious so far. Another fix will be submitted for the
original issue.
Python scripts could perform actions that created notifiers
which would not be handled until the script was complete.
In the case of adding & removing objects a notifier would be created
for adding the object, then cleared when the ID was removed.
This lead to the notifier queue filling up with cleared notifiers
which were included in the search whenever an ID was removed.
The result of this was that adding and removing objects from a script
would become increasingly slower & use more memory.
Resolve by storing the current notifier being handed which isn't freed
(only cleared). The notifier handling loop detects cleared notifiers
and frees them after use.
PR #128051 made some improvements to code by cleaning up properties and
simplifying logic.
However, the default tool in most spaces is box select. By switching to
box select default, there should be more front-facing consistency across
spaces while still retaining near-identical behavior.
This patch would fix the small bug listed in #128671 while keeping the
simplified code benefits from #128051.
Also:
- Move selection keymap items up in the Sequencer (Global) keymap so it
is more visible (similar to Node Editor ordering).
- Split `side_of_frame` property for ctrl press keymap item into a
separate keymap item on ctrl click for both LCS and RCS to avoid
clashing with ctrl+drag for box selects in RCS.
Pull Request: https://projects.blender.org/blender/blender/pulls/129028
Essentially, our current code would not properly remove (dereference)
its python objects matching various RNA data created during execution.
Some cases are fairly trivial to understand (like the lack of handling
of unregstering for our 'startup' operators and UI), other were more
subtle (like unregistered PropertyGroups who would remove/free their RNA
struct definition, without releasing first the potential matching python
object).
Co-authored-by: Campbell Barton <campbell@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/128899
The problem was that the screen space size of the brush was not updated.
This was not fully noticeable because the radius control operator was using
a not working scale correction.
The solution remove the scale correction and just update the brush size.
Note: This update currently happens when the cursor is drawn.
Pull Request: https://projects.blender.org/blender/blender/pulls/126773
The problem was that the screen space size of the brush was not updated.
This was not fully noticeable because the radius control operator was using
a not working scale correction.
The solution remove the scale correction and just update the brush size.
Note: This update currently happens when the cursor is drawn.
Pull Request: https://projects.blender.org/blender/blender/pulls/126773
Followup to 682161283e.
This type better reflects the intention of a read-only string reference,
and `std::string` should usually be used for owning string variables
only.
The tool-tip generated for FileHandler drag-n-drop may be obtained from a
different context where the dropbox poll function is invoked, which could
generated an incorrect tool-tip since FileHandlers are polled again in a wrong
context.
This can be solved by ensuring the same context is used, however the tool-tip
could be drawn in different windows.
To avoid undefined tool-tips , this generates the tool-tip in place when the
dropbox poll function is invoked.
Pull Request: https://projects.blender.org/blender/blender/pulls/125037
Due to rounding errors in `wm_gesture_straightline_do_angle_snap`, it
could give out a snapped result that's meant to be 45 degrees but does
not have equal X/Y distances after converted to integer. Since 45
degrees can be used to make a equal length structure, it's best to make
sure that resulting X/Y values are the same if the angle is multiple of
45 degrees.
This fix would be effective for all tools that uses this "straight line
gizmo".
Pull Request: https://projects.blender.org/blender/blender/pulls/128683
Due to rounding errors in `wm_gesture_straightline_do_angle_snap`, it
could give out a snapped result that's meant to be 45 degrees but does
not have equal X/Y distances after converted to integer. Since 45
degrees can be used to make a equal length structure, it's best to make
sure that resulting X/Y values are the same if the angle is multiple of
45 degrees.
This fix would be effective for all tools that uses this "straight line
gizmo".
Pull Request: https://projects.blender.org/blender/blender/pulls/128683
Second part to fix#128420.
On startup, the Blender File Outliner mode would show empty libraries
linked, pointing to the brush essentials files. This was because some
grease pencil versioning code would call
`BKE_paint_ensure_from_paintmode()`, which would link in the default
brushes. Then a bit later, brush assets versioning code would remove
local brushes from the default starup file, so the library link became
empty.
Initializing paint data shouldn't necessarily include importing default
brushes. In an earlier version I made this optional with a boolean, but
it's easy enough to separate out entirely.
Now `BKE_paint_ensure()` just initializes paint data, and
`BKE_paint_brushes_ensure()` has to be called to ensure that active
brushes are available.
Pull Request: https://projects.blender.org/blender/blender/pulls/128801
Blender crashes when opening a file that has an interactive compositor
active, while also having a script that invokes the compositor upon file
load.
This is caused by the same system GPU context being active in two
threads at the same time, which happens when the GPU context for the
compositor is created in the main thread, it is made current during
creation, but it is not reset to the main GPU context of the drawable
because it is null. So when the GPU compositor actually executes, it
makes the GPU context current again but in its own thread, causing a
BadAccess error in X11 and potentially other window systems.
The reason why the drawable is nullptr is because it is reset in the
existing window manager when opening a new file while Blender is open,
but it is never initialized for the new window manager. The drawable
info should be moved from the old window manager to the new window
manager in wm_file_read_setup_wm_use_new, but it is preemptively reset
by the wm_window_clear_drawable call before it it is moved. This is done
in wm_file_read_setup_wm_substitute_old_window.
So to fix this, we move wm_window_clear_drawable after the code block
where wm_file_read_setup_wm_substitute_old_window gets called.
This renames the mode identifiers to be consistent with e.g. the context mode identifiers and other names used for the new Grease Pencil.
For `object.mode`:
* `PAINT_GPENCIL` -> `PAINT_GREASE_PENCIL`
* `SCULPT_GPENCIL` -> `SCULPT_GREASE_PENCIL`
* `VERTEX_GPENCIL` -> `VERTEX_GREASE_PENCIL`
* `WEIGHT_GPENCIL` -> `WEIGHT_GREASE_PENCIL`
For the internal `ob->mode` flag:
* `OB_MODE_PAINT_GPENCIL_LEGACY` -> `OB_MODE_PAINT_GREASE_PENCIL`
* `OB_MODE_SCULPT_GPENCIL_LEGACY` -> `OB_MODE_SCULPT_GREASE_PENCIL`
* `OB_MODE_VERTEX_GPENCIL_LEGACY` -> `OB_MODE_VERTEX_GREASE_PENCIL`
* `OB_MODE_WEIGHT_GPENCIL_LEGACY` -> `OB_MODE_WEIGHT_GREASE_PENCIL`
Resolves#127374.
Pull Request: https://projects.blender.org/blender/blender/pulls/128604
Removes many of the operators, panels, and menus used exclusively by Grease Pencil v2 that are no longer needed in v3.
No functional changes are expected.
Some operators are still used by the annotations system and have to be kept around. These may be renamed in future.
Pull Request: https://projects.blender.org/blender/blender/pulls/128521
The `pre` handler is called after blender internal code is done populating
the link/append context with data to be processed, and before this data
starts being linked from library files.
The `post` handler is called after blender is done linking, and
potentailly appending and/or instantiating, the requested data and all
of their dependencies.
Both handlers are called with a single argument, the link/append
context.
An new RNA sets of wrappers have been added to expose relevant info from
these internal C++ structures.
NOTE: !113658 is very similar (but tied to asset drag & drop), whereas
this PR is more general (these could probably live hand-in-hand / side-
by-side).
Implements #122357
Pull Request: https://projects.blender.org/blender/blender/pulls/128279
-----------------
Some quick py example code:
```python
import bpy
def my_handler_pre(lapp_context):
print("About to {}:\n\t".format("link" if "LINK" in lapp_context.options else "append"),
"\n\t".join("{} '{}', from libs ['{}']".format(item.id_type, item.name,
"', '".join([l.filepath for l in item.source_libraries]))
for item in lapp_context.import_items))
def my_handler_post(lapp_context):
print("{}:\n\t".format("Linked" if "LINK" in lapp_context.options else "Appended"),
"\n\t".join("{} '{}', from lib '{}'".format(item.id.id_type, item.id.name, item.source_library.filepath)
for item in lapp_context.import_items))
bpy.app.handlers.link_append_pre.append(my_handler_pre)
bpy.app.handlers.link_append_post.append(my_handler_post)
```
As discussed in #128066, we want that activating a brush makes sure the
most appropriate tool is activated. For example activating an eraser
brush should activate an eraser tool, if available. This makes the
tool and brush binding two ways, which is more clear. Plus it means that
users don't have to care about tools at all if they don't want to, they
can just keep switching brushes and Blender takes care of the tool.
Implementation wise, this works by letting a Python operator lookup a
tool for a given brush type name, when activating a brush.
Design Task: https://projects.blender.org/blender/blender/issues/128066
When attempting to load a blend file that is not found or otherwise
invalid we are currently showing an (ugly) popup menu report and then
clearing the item from the Recent Files list. Clearing the list could
be unwanted in the case of files that are temporarily offline. And we
now have the ability to only clear "Items not found" using the "Clear
Recent Files List" operator. This PR removes that clearing.
Pull Request: https://projects.blender.org/blender/blender/pulls/127882
We'd first set the brush, then change tools, which would again set the
brush to what it was before (switching tools tries to remember its last
used brush). Instead, switch the brush after switching the tool.
Also added a brush API check to test if the brush is valid for the
current mode, so that we don't end up switching tools in that case. This
matches previous behavior where this would be checked as part of setting
the brush already, causing the function to early exit before the tool is
changed.
Getting the active tool from context doesn't work exactly when executed
from the properties editor, which shows the active tool settings of the
3D view. Make the brush tool code fallback to the active tool from the
3D view, so it can be called from the properties.
Order of operations was wrong: First, the new tool has to be activated
(or at least identified) before we can tell which tool (or more precise,
which brush type) to update the brush binding for.
When I was learning VSE code, MAXSEQ constant (a preprocessor define!) was
confusing. It makes it sound like it is "max sequences", but it is actually
"max channels". So rename it to SEQ_MAX_CHANNELS and make it C++ constexpr int
instead of preprocessor macro.
Pull Request: https://projects.blender.org/blender/blender/pulls/128024
