Depending on compiler and bitness, size_t and uint64_t can be different
types. Since uint64_t format is used explicitly cast size_t to uint64_t
to solve compiler warning.
Happens with Clang 15 on macOS.
Tested with IBUS on GNOME 45.
Added a capabilities flag to GHOST since support for IME works on
Wayland but not on X11, so runtime detection is needed.
wmJob's shared data (with their worker threads), #wmJobWorkerStatus, now
also contains a #ReportList pointer.
Job worker code is now expected to use `BKE_report` APIs to populate this
new shared reportlist, instead of calling the (absolutely) not
thread-safe `WM_reports` API. This will be tackled in later commits.
Note that since commit 9859622a66, #ReportList and `BKE_report` API
is now thread-safe, so no further handling for this is required in the
wmJob code itself.
The periodic wmJob update handling (done through timers currently)
takes care of moving reports from the job data to the WM data.
Implements #112537.
Pull Request: #113548.
There was already such a `wm_add_reports` function, but it was private.
It is now available in the public API, and renamed to
`WM_reports_from_reports_move`.
Only expand image sequences when a single file is passed in.
This allows shell globing to expand images without expanding each.
Prepare for support multiple file drag & drop where it also doesn't
make sense to expand sequences when dropping multiple files.
This commit makes using (most of) `BKE_report` API safe in
multi-threaded situation.
This is achieved by adding a `std::mutex` lock to the `ReportList`
struct (in a slightly convoluted way unfortunately, due to this being a
DNA struct). This lock is then used to make most operations on
`Reportlist` data thread-safe.
Note that while working on this, a few other minor issues aroze in
existing usages of Reportlist by the WM code, mainly the fact that
`wm_init_reports` and `wm_free_reports` were both useless:
- init was called in a context where there is not yet any WM, so it
was doing nothing.
- free was called on a WM that would be later freed (as part of Main
freeing), which would also call cleanup code for its `reports` data.
Both have been removed.
Further more, `wm_add_default` (which is the only place where a WM ID is
created) did not initialize properly it reports data, this has been
fixed.
This change is related to the wmJob thread-safety tasks and PRs (#112537,
!113548).
Pull Request: https://projects.blender.org/blender/blender/pulls/113561
Resolve issues with the animation player drag & drop.
- IMB_exit ran before attempting to load the dropped image,
crashing when the image was loaded.
- The old event consumer wasn't removed from the system
causing events to be processed that accessed freed stack memory.
Regression caused by [0]. Resolve by adding a 'keep_properties' argument
to KeyConfig.update so the key-map items can be restored after the
operators have been reloaded.
[0]: 88a875ec3a
Resolve issues with corner-cases introduced by [0].
- Comparing the filename & filepath was no longer a valid way to check
for a directory component since the extension was stripped.
- Use BLI_path_extension_or_end which doesn't confuse extensions with
the dot from hidden files.
The variable name include_directory was also misleading.
[0]: 1a648f5b22
These callbacks were named for the purpose of drawing (and that's probably
their main use case still), but nothing limits them to be used for that only.
They can be useful for non-drawing related things, essentially they act as
drop-box entering and exiting event handlers. Reflect that in the name, so also
more clear when they will be called, as opposed to what they are typically used
for. Drop-boxes already have such event handler callbacks, this makes their API
naming more consistent.
Also better differentiates between drawing and handling callbacks, the
difference matters (attempting to draw during handling won't work).
No functional changes
Since the functions now live in a namespace,
they no longer need the prefix
as a result there are now 2 functions named
`autokeyframe_object`
which is fine because they take different parameters
If both are needed is for a future patch to investigate
Pull Request: https://projects.blender.org/blender/blender/pulls/113612
No functional changes
The following functions have been moved
`autokeyframe_cfra_can_key`
`autokeyframe_object`
`ED_autokeyframe_object`
`ED_autokeyframe_pchan`
`ED_autokeyframe_property`
they are all in a new file
keyframing_auto.cc
while the declarations are in
ANIM_keyframing.cc
The autokeyframe makros also have been moved
Pull Request: https://projects.blender.org/blender/blender/pulls/113607
