Commit Graph

6 Commits

Author SHA1 Message Date
Sergey Sharybin c1bc70b711 Cleanup: Add a copyright notice to files and use SPDX format
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/
2023-05-31 16:19:06 +02:00
Campbell Barton 3958ae7241 Cleanup: use STRNCPY, SNPRINTF macros 2023-05-09 14:08:19 +10:00
Campbell Barton 6859bb6e67 Cleanup: format (with BraceWrapping::AfterControlStatement "MultiLine") 2023-05-02 09:37:49 +10:00
Julian Eisel d90795bc3c Asset System: New "weak" asset reference for storing in .blend files
No user visible changes expected.

For brush assets, we need a way to store a reference to a brush in .blend files, so that the last active brush can be restored from the file. See #101908. It seems like a generally useful thing to have.

Adds a new DNA struct to store a "weak" asset reference, that is, a reference that can break under a number of circumstances, but should work reliably enough under normal usage. There's no way to reliably reference an asset currently, so this works on a "best effort" basis. It can break when assets are moved inside the asset library, asset libraries are unregistered from the Preferences, or a file is opened on a different machine with different Preferences, for example. It can also break currently if an asset library is renamed.
It contains:
- Information to identify the asset library the asset can be found in.
- A relative "identifier" (currently a relative path) for the asset within the asset library.

There's further code to resolve a weak reference to file paths and Blender library paths.

Part of #101908.

Co-authored-by: Bastien Montagne <bastien@blender.org>

Pull Request: https://projects.blender.org/blender/blender/pulls/105603
2023-03-30 12:25:42 +02:00
Sergey Sharybin a12a8a71bb Remove "All Rights Reserved" from Blender Foundation copyright code
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.
2023-03-30 10:51:59 +02:00
Julian Eisel ea2dda306c Asset system: New asset system code module (with files from BKE)
Adds a new `source/blender/asset_system` directory and moves asset
related files from BKE to it. More asset related code can follow
(e.g. asset indexing, ED_assetlist stuff) but needs further work to
untangle it. I also kept `BKE_asset.h` and `asset.cc` as is, since they
deal with asset DNA data mostly, thus make sense in BKE.

Motivation:
- Makes the asset system design more present (term wasn't even used in
  code before).
- An `asset_system` directory is quite descriptive (trivial to identify
  core asset system features) and makes it easy to find asset code.
- Asset system is mostly runtime data, with little relation to other
  `Main`/BKE/DNA types.
- There's a lot of stuff in BKE already. It shouldn't be just a dump for
  all stuff that seems core enough.
- Being its own directly helps us be more mindful about encapsulating
  the module well, and avoiding dependencies on other modules.
- We can be more free with splitting files here than in BKE.
- In future there might be an asset system BPY module, which would then
  map quite nicely to the `asset_system` directory.

Checked with some other core devs, consensus seems that this makes
sense.
2022-11-14 12:46:34 +01:00