Context is needed to import and instantiate assets correctly. Previously
the context was stored as "evil" pointer in the drag data. Since
77794b1a7b, context is passed to the dragging callbacks doing the asset
import, so the context doesn't need to be stored that way anymore and
can simply be passed to the import function.
This implements the main aspects of changes to blendfile compatibility
as designed in #109151:
* Blender files which file minversion is newer than current Blender
executable won't be loaded at all.
* Blender files which file version is newer than current Blender will
triger systematic warning to user:
* In the status info bar (lower right corner in default UI).
* When attempting to save (overwrite) them.
This means that the file minversion becomes a hard limit, and not a
soft, warning-only as it used to be. Further more, forward compatibility
warning is now systematic (instead of depending on file minversion),
and more visible for users.
See also https://wiki.blender.org/wiki/Process/Compatibility_Handling
for details over the new policy.
Technically:
* Opening any file with a minversion newer than current Blender file one
now triggers an early abort, with an error message reported to the user.
This is handled by a new utils called from `blo_decode_and_check`.
* Any file newer than current Blender version sets a new
`has_forward_compatibility_issues` flag in Main struct at read time.
* Status bar info area is turned into a template, which uses this flag
to display special warning UI and tooltip when set.
* A new confirmation popup appears when user tries to save (overwrite)
such a 'newer' blendfile, stating potential loos of data, and
proposing by default to 'save as' instead.
* The 'quit unsaved' popup has also been updated to 'save as' instead of
'save' when the edited file is has potential forward compitibility
issues.
Part of #109151 (PR !110109).
The cleanup of blenkernel last weeks , caused the house of cards to
collapse on top of bf_gpu's shader_builder, which is off by default
but used on a daily basis by the rendering team.
Given the fixes forward in #110394 ran into a ODR violation in OSL that
was hiding there for years, I don't see another way forward without
impeding the rendering teams productivity for "quite a while" as there
is no guarantee the OSL issue would be the end of it.
the only way forward appears to be back.
this reverts :
19422044eda670b53abe0f541db97cbe516e8c813e88a2f44c4e64b772f59547e7a31707fe6c5a57
The problematic commit was 07fe6c5a57
as blenkernel links most of blender, it's a bit of a link order issue
magnet. Given all these commits stack, it's near impossible to revert
just that one without spending a significant amount of time resolving
merge conflicts. 99% of that work was automated, so easier to just
revert all of them, and re-do the work, than it is to deal with the
merge conflicts.
Pull Request: https://projects.blender.org/blender/blender/pulls/110438
Regression in [0] changed the order of execution for the load_post
handler which previously (in 3.5x) ran before driver evaluation.
Calling either load_post/load_post_fail handlers after loading was
changed intentionally to simplify the code-path for calling handlers
however it meant the handler couldn't be used to setup drivers,
so restore the original logic.
[0]: 46be42f6b1
Resolve a crash in !104831, which exposed an error in window creation
with an empty space type.
Creating a new window with an empty space type would do the following:
- Create a new screen with a single empty area.
- Refresh the screen,
- Initialize the area.
- Convert the empty area into a 3D viewport.
- Run SpaceType::init()
This doesn't cause any problems at the moment because `view3d_init`
isn't doing anything however !104831 accesses the View3D from
`area->spacedata.first` causing SCREEN_OT_area_dupli to crash.
Resolve by supporting an area setup callback for WM_window_open
so the area-data can be set before it's initialized.
The issue remains where an unknown/empty ScrArea::spacetype results in
a crash although it seems unlikely users run into this in practice.
Whatever the case, that can be resolved separately.
This change replaces a bare RenderEngine owned by a viewport
with a VeiwRender. This unlocks a possibility of accessing
RenderResult for viewport renders. Currently it is not done,
but it will be needed for an upcoming work towards unification
of the render passes handling.
Ref #108618
Pull Request: https://projects.blender.org/blender/blender/pulls/110244
Caused by fd3e44492e.
Images were drawn filling the entire window, now use available size/
offset inside the window and pass these as `rctf` to
`draw_display_buffer`.
Should be good for 3.6/3.3 LTS
Pull Request: https://projects.blender.org/blender/blender/pulls/110206
File > New> General tooltip is misleading, as explained in issue #109875
Changes the tooltip from the current "Open the default file (doesn't save the current file)" to simply "Open the default file".
It could be argued that the note is still valid for when people have Preferences > Save & Load > Save Prompt disabled, but we don't have a similar note in any of the other cases that open a different file.
Pull Request: https://projects.blender.org/blender/blender/pulls/110086
Use modifier keys that are pressed before activating a new window.
Allows call of `wm_window_update_eventstate_modifiers` on
`GHOST_kEventWindowActivate` by using `GetAsyncKeyState` instead of
`GetKeyState` in GHOST_SystemWin32::getModifierKeys, which retrieves
actual hardware state.
Pull Request: https://projects.blender.org/blender/blender/pulls/110020
This formats code that is disabled using `#if 0`. Formatting was achieved
by temporarily changing `#if 0` to `#if 1 /*something*/`, then formatting,
and then changing it back to `#if 0`.
Now that liboverride process on save (the diffing + pruning unused
override operations + reset of non-overridable changes) works better. it
leads to a bad side-effect: all system overrides data indirectly
modified through animation or drivers get reset.
Since in current system e.g. most objects of a rigged asset are system
overrides, but their transform is modified by bones animation, this
leads to entire overrides of assets being reset to their linked state
until next depsgraph evaluation.
While this is the expected and correct behavior in absolute, this is
very bad from a user experience PoV.
This commit address the issue by simply re-running a 'frame change'
despgraph update, to ensure all drivers, animations etc. are properly
re-applied after liboverride diffing cleanup & reset.
Note: Change applies to Grease Pencil 3.0 only (experimental feature).
Enables use of drag & drop to reorder grease pencil layers through the layer
tree UI, as well as inserting layers into groups. This is an intuitive and
often requested method of managing such data-structures. Visual feedback should
be improved still, and the gap between items be removed, to reduce flickering
while dragging. These are general improvements for tree views however which
should be done separately.
There is no support yet for dragging layer groups, this requires further
changes in the internal grease pencil APIs.
#109825 introduced the necessary drag & drop support for tree views, #109824
prepared the internal grease pencil API for it.
Pull Request: https://projects.blender.org/blender/blender/pulls/109826
Avoid potential problems when the active window is known but not
assigned to `wm->winactive`, where the first window would be used
as a fallback. Instead, take a window argument, a fallback is still
used as a last resort (when NULL).
