There's quite a few libraries that depend on dna_type_offsets.h
but had gotten to it by just adding the folder that contains it to
their includes INC section without declaring a dependency to
bf_dna in the LIB section.
which occasionally lead to the lib building before bf_dna and the
header being missing, while this generally gets fixed in CMake by
adding bf_dna to the LIB section of the lib, however until last
week all libraries in the LIB section were linked as INTERFACE so
adding it in there did not resolve the build issue.
To make things still build, we sprinkled add_dependencies wherever
we needed it to force a build order.
This diff :
Declares public include folders for the bf_dna target so there's
no more fudging the INC section required to get to them.
Removes all dna related paths from the INC section for all
libraries.
Adds an alias target bf:dna to signify it has been updated to
modern cmake
Declares a dependency on bf::dna for all libraries that require it
Removes (almost) all calls to add_dependencies for bf_dna
Future work:
Because of the manual dependency management that was done, there is
now some "clutter" with libs depending on bf_dna that realistically
don't. Example bf_intern_opencolorio itself has no dependency on
bf_dna at all, doesn't need it, doesn't use it. However the
dna include folder had been added to it in the past since bf_blenlib
uses dna headers in some of its public headers and
bf_intern_opencolorio does use those blenlib headers.
Given bf_blenlib now correctly declares the dependency on bf_dna
as public bf_intern_opencolorio will get the dna header directory
automatically from CMake, hence some cleanup could be done for
bf_intern_opencolorio
Because 99% of the changes in this diff have been automated, this diff
does not seek to address these issues as there is no easy way to
determine why a certain dependency is in place. A developer will have
to make a pass a this at some later point in time. As I'd rather not
mix automated and manual labour.
There are a few libraries that could not be automatically processed
(ie bf_blendthumb) that also will need this manual look-over.
Pull Request: https://projects.blender.org/blender/blender/pulls/109835
Part of the checks to see if translating a UI string is allowed or not
is that current thread is the main one. This was a requirement years ago
of the Boost backend for translations.
Not sure whether this can be removed or not now, but it needs to be
carefully checked, done it as its own commit, and not in a beta release
branch. ;)
Sorry for the noise, totally missed this during the patch review
yesterday.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
- "Out" meaning "one end of a bone". Same as in 9120c86c3f.
- "Canvas" meaning a painting support for Dynamic Paint.
- "Twist" meaning an action verb, as opposed to an amount.
- "Solid" meaning a textureless, single-color material.
- "Blend mode" meaning material opacity blending, as opposed to color
blending.
- "Pixel Size" meaning "a size measured using pixels as the unit".
- "Light" meaning "not dark", as in "Light Theme".
Ref #43295
- "Lens" can be a transparent object used in cameras, or specifically
its property of focal length
- "Empty" can be an adjective meaning void, or an object type. The
latter is already disambiguated using `ID_ID`
- "New" and "Old" are adjectives that can have agreements in some
languages
- "Modified" is an adjective that can have agreement in some languages
- "Clipping" can be a property of a camera, or a behavior of the
mirror modifier
- "Value" in HSV nodes, see #105113
- "Area" in the Face Area geometry node, can mean a measurement or a
window type
- "New" is an adjective that can have agreement
- "Tab" can be a UI element or a whitespace character
- "Volume" can mean a measurement or an object type. The latter is
already disambiguated using `ID_ID`
These changes introduce the new `BLT_I18NCONTEXT_TIME` translation
context.
They also remove `BLT_I18NCONTEXT_VIRTUAL_REALITY`, which I added at
one point but then couldn't find which messages I wanted to fix with
it.
Ref #43295
Pull Request: #106718
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
- "Lines" in the sense of number of lines
- "Number" can mean "amount, count" or "index, offset"
- "Second" can be an ordinal number or a unit
- "Root": add the brush curve to the "square root falloff" sense
- "Strip" can be a sequence or a type of hair rendering
- "Constant" in the sense of a value, for the Geometry Nodes add
submenu (#105447).
Additionally, extract:
- "Press a key" from the Keymap preferences.
- "MaskLayer", upon new mask layer creation
Ref #43295, #105447
- "Value" in the sense of color lightness is not the same word in
Japanese as other usages. See #105113.
- "Double" as a data type vs. a value.
Also extract "Custom Color Presets" in the tracking UI.
Run clang-format as well.
Pull Request #105187
After rBdb87e2a638f9, two contexts were missing:
- VirtualReality, to be used in an add-on
- Constraint, used in the constraints UI
The latter was actually used without being added, which caused errors.
It was reverted in rB31a640027982.
Extract:
- EEVEE: Compiling Shaders (the same message exists in EEVEE Next, but
it uses string concatenation and I don't know yet how to deal with
those--see T92758)
Disambiguate:
- Pan (audio, camera)
- Box (TextSequence)
- Mix (noun in constraints, GP materials)
- Volume (object type, file system)
- Floor (math integer part, 3D viewport horizontal plane)
- Impossible to disambiguate the constraint name because
bConstraintTypeInfo doesn't have a context field.
- Show Overlay (in the sequence editor, use the same message as other
editors to avoid a confusion with the Frame Overlay feature, also
called "Show Overlay")
Additionally, fix a few issues reported by Joan Pujolar (@jpujolar)
in T101830.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D17114
These functions are almost identical, the main difference being
BLI_join_dirfile didn't trim existing slashes when joining paths
however this isn't an important difference that warrants a separate
function.
Thumbnails of fonts that better show design, shapes, contents, intent,
and intended language. Previews almost every known language - living
and dead - and symbol, specialty fonts, etc.
See D12032 for more details and samples.
Differential Revision: https://developer.blender.org/D12032
Reviewed by Campbell Barton
Removal of BLT_lang_is_ime_supported which is always returns true and
is no longer needed.
See D11800 for more details.
Differential Revision: https://developer.blender.org/D11800
Reviewed by Campbell Barton
This commit renames enums related the "Curve" object type and ID type
to add `_LEGACY` to the end. The idea is to make our aspirations clearer
in the code and to avoid ambiguities between `CURVE` and `CURVES`.
Ref T95355
To summarize for the record, the plans are:
- In the short/medium term, replace the `Curve` object data type with
`Curves`
- In the longer term (no immediate plans), use a proper data block for
3D text and surfaces.
Differential Revision: https://developer.blender.org/D14114
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
Previously, macros were ifdefed using the cmake option `WITH_INTERNATIONAL`
However, the is unnecessary as withen the functions themselves have checks for building without internationalization.
This also means that many `add_definitions(-DWITH_INTERNATIONAL)` are also unnecessary.
Reviewed By: mont29, LazyDodo
Differential Revision: https://developer.blender.org/D13929
Blender did not support to input East Asian characters (Chinese, Japanese,
Korean) on macOS. This patch adds support for Japanese input, by implementing
the appropriate processing for the NSTextInputClient protocol.
Technical notes:
* The conversion candidate window is drawn by the input method program calling
`firstRectForCharacterRange`.
* The string before confirmation (called `composite` in blender) is handled in
the `setMarkedText` method called by the input method program.
* The string after confirmation (called `result` in the blender) is processed
in the `insertText` method called by the input method program.
Ref T51283
Differential Revision: https://developer.blender.org/D11695
The impact of translations on UI performances is neglectable, and this
gives better handling of some odd cases where original language of an
add-on is not English.
Allow OS input language to initiate IME, regardless of Blender output language.
Differential Revision: https://developer.blender.org/D10268
Reviewed by Julian Eisel
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule. This should be the final commit of the series of commits that
addresses this particular rule.
No functional changes.
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
Changing from IME-enabled language to English did not turn off IME.
Differential Revision: https://developer.blender.org/D7486
Reviewed by Campbell Barton
This data block will be the container for simulation node trees.
It will be used for the new particle node system (T73324).
The new data block has the type `ID_SIM`.
It is not visible to users and other developers by default yet.
To enable it, activate the cmake option `WITH_NEW_SIMULATION_TYPE`.
New simulation data blocks can be created by running `bpy.data.simulations.new("name")`.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7225
