A small quality of life change to indicate which slots are used.
This only applies to the slots menu, the UI List could show these too
however this requires extending the RNA API.
Ref: !138651
The conversion from int to float is not supported natively
so it ends up happening beforehand on the CPU or as a
step before the vertex buffer can be used. It's better to just
upload floats in the first place.
Related to:
- 1e1ac2bb9b
- 617858e453
Pull Request: https://projects.blender.org/blender/blender/pulls/138855
This merges the public `uiItemS` and `uiItemS_ex` functions into an
object oriented API (`uiLayout::separator`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code
(or vice-versa), making it almost seamless.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138826
This converts the public `uiItemO` function to an object oriented
API (`uiLayout::op`).
Also this rearranges `idname` paramether, since this the only one
required, and to make format similar to `uiItemFullO`
Note: One of the benefits of moving from a public function to class
method is to reduce API usage difference between C++ and Python. In
Python this method is called `UILayout::operator`, however `operator`
is a reserved keyword in C++.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138776
This converts the public `uiItemR` function to an object oriented
API (`uiLayout::prop`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138617
This converts the public `uiItemL` function to an object oriented
API (`uiLayout::label`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138608
Like other runtime structs, it doesn't make sense to write this
data to files. And moving it out of DNA to an allocated C++ struct
means we can use other C++ features in it, like the new Mutex
type which I switched to in this commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/138551
This converts the public `uiLayoutColumn` function to an object oriented
API (`uiLayout::column`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
`uiLayout::column` now returns an `uiLayout` reference instead of a pointer.
New calls to this method should use references too.
Pull Request: https://projects.blender.org/blender/blender/pulls/138034
This converts the public `uiLayoutRow` function to an object oriented
API (`uiLayout::row`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
`uiLayout::row` now returns an `uiLayout` reference instead of a pointer.
New calls to this method should use references too.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/137979
It's safer to pass a type so that it can be checked if delete should be
used instead. Also changes a few void pointer casts to const_cast so that
if the data becomes typed it's an error.
Pull Request: https://projects.blender.org/blender/blender/pulls/137404
This adds initial support for showing logged data in closures. This is more
tricky than the other zone types, because the zone content is evaluated
elsewhere. The main new thing here is a function that attempts to find where a
given closure is evaluated statically.
Finding this place statically is also important because we generally decide
which compute contexts we want to log before evaluation starts. That's because
we don't want to log everything (which is expensive), but just the places that
the user is currently looking at.
This also changed a bunch of CMakeLists.txt files so that these modules can
include NOD_* stuff, which is generally fine everywhere in editors code.
Pull Request: https://projects.blender.org/blender/blender/pulls/137403
**Problem**
When using Texture Paint mode, the Image Editor will show a UV Wireframe
to display the active object's UVs. In every other mode, this wireframe
is absent. This is currently a big problem for Sculpt Mode since the
Experimental Texture Paint system is a part of that mode, meaning that
the user can't see their UVs while they paint in Sculpt Mode. This is
also troublesome for users that would like to quickly view an object's
UVs without using Texture Paint Mode.
**Solution**
Since it's useful to be able to view an object's UVs at all times, the
Image Editor should display UV Wireframes in all Object Modes regardless
of the Image Editor's mode. This is the best solution since it means
that future Blender features, that would benefit from having a preview
of an object's UV Wireframes, will automatically have that option since
UV Wireframes are supported in all modes. Also, if a user doesn't want
to see UV Wireframes for any reason, it can be disabled with an Overlay
option.
Additionally, when multiple objects are selected, each object should
have its UV Wireframe drawn in the Image Editor. The selected objects
that aren't active should have less opaque wireframes to indicate which
wireframe belongs to the active object. This is the best approach for
having multiple objects selected since it allows the user to quickly
view the UV layout for all selected objects to troubleshoot UV problems,
like texture mapping. This is especially helpful when using a material
for multiple different objects.
An alternative solution would be to only show the UV Wireframe for the
active object, but this would be undesirable because it would make
troubleshooting UV positions tedious when working with multiple objects
since the user would need to select objects individually.
Co-authored-by: T0MIS0N <50230774+T0MIS0N@users.noreply.github.com>
Co-authored-by: Sean Kim <SeanCTKim@protonmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/135102
This fixes most "One Definition Rule" violations inside blender proper
resulting from duplicate structures of the same name. The fixes were
made similar to that of !135491. See also #120444 for how this has come
up in the past.
These were found by using the following compile options:
-flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
Note: There are still various ODR issues remaining that require
more / different fixes than what was done here.
Pull Request: https://projects.blender.org/blender/blender/pulls/136371
Use enum types for event modifier and types,
`wmEventModifierFlag` & `wmEventType` respectively.
This helps with readability and avoids unintended mixing with other
types. To quiet GCC's `-Wswitch` warnings many `default` cases needed
to be added to switch statements on event types.
Ref !136759
Set the flags on the image buffer when loading an EXR file, so they can be
used when saving.
This also removes IB_halffloat and replaces it by the file options flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/135656
Callbacks: exec invoke & modal now use a typed enum wmOperatorStatus.
This helps avoid mistakes returning incompatible booleans or other
values which don't make sense for operators to return.
It also makes it more obvious functions in the WM API are intended
to be used to calculate return values for operator callbacks.
Operator enums have been moved into DNA_windowmanager_enums.h
so this can be used in other headers without loading other includes
indirectly.
No functional changes expected.
Ref !136227
Use anonymous namespace to prevent naming collision allocating
structs of the same name.
Should resolve#134419 although I was unable to redo this bug.
Ref !135726
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
This reverts commit afec64739a.
The commit introduces a regression where opening the Asset Browser opens
the File Browser instead, same for other editor sub-types, see
blender/blender#134630.
blender/blender!134642 proposes a different solution and reverts this,
which I prefer too. Better to the revert separately from trying a
different fix for the initial bug, makes reviewing easier too.
This implements the memorization of the previous state of a space's
subtype for those that have multiple modes. Introduces an optional
space_subtype_prev_get callback, implemented for SPACE_ACTION,
SPACE_FILE, SPACE_GRAPH, SPACE_IMAGE and SPACE_NODE. This means we
can always return to the previous mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/133846
The usual issue of non-trivial C++ data being allocated with C-style
`alloc` code.
Also added more default initializers to some generic RNA-related structs
that embded some `PointerRNA` members.
Move `Library.runtime` to be a pointer, move the related
`LibraryRuntime` struct to `BKE_library.hh`. Similar to e.g.
Mesh.runtime, that pointer is expected to always be valid, and is
allocated at readtime or when creating a new Library ID.
Related smaller changes:
* Write code now uses standard ID writing codepath for Library IDs too.
* Runtime pointer is reset to nullptr before writing.
* Looking up a library by its absolute path is now handled through a
dedicated utils, `search_filepath_abs`, instead of using
`BLI_findstring`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134188
Yet another remaining case of non-trivial data created with C-style
allocation.
While 4.4 and previous did not exhibit the crash, the invalid code
responsible for this crash is present here as well, and it would be
dangerous not to fix it.
Add proper checks for editable ID to image pack/unpack and file_browse
operators.
Also add similar check to `unpack_item` operator, although in that case
the check has to happen in exec callback, as poll function would not
have required info.
