In order to achieve this, the TagLib_File type of the C bindings is now
a FileRef and no longer a File. The support for the .oga extension has been
ported to FileRef(), so that taglib_file_new() should still behave the
same, but additionally also support content based file type detection.
Use of FileRef::file() is discouraged, but was necessary to access the
properties. It was also not clear whether to access the properties via
tag() or file(). With the property methods on FileRef, it should become
the "simple usage" interface it was meant to be.
As the destructor was the only virtual method on FileRef, it is now made
non-virtual. Probably, it is not useful as a virtual base class.
Also modernize and simplify code, fix formatting, support
ID3v2FrameFactory, fix updating the internal chunk bookkeeping
after file modifications, stripping ID3 and DIIN tags.
Provides a unified API for complex properties in the same way as
the Properties API in the C bindings. Since constructing and
traversing complex properties in C is a bit complicated, there
are convenience functions for the most common use case of getting
or setting a single picture.
TAGLIB_COMPLEX_PROPERTY_PICTURE(props, data, size, "Written by TagLib",
"image/jpeg", "Front Cover");
taglib_complex_property_set(file, "PICTURE", props);
and
TagLib_Complex_Property_Attribute*** properties =
taglib_complex_property_get(file, "PICTURE");
TagLib_Complex_Property_Picture_Data picture;
taglib_picture_from_complex_property(properties, &picture);
Provides a dynamic interface for properties which cannot be represented
with simple strings, e.g. pictures. The keys of such properties can
be queried using `complexPropertyKeys()`, which could return for example
["PICTURE"]. The property can then be read using
`complexProperties("PICTURE")`, which will return a list of variant maps
containing the picture data and attributes. Adding a picture is as
easy as
t->setComplexProperties("PICTURE", {
{
{"data", data},
{"pictureType", "Front Cover"},
{"mimeType", "image/jpeg"}
}
});
cmake supports both absolute and relative to prefix install dirs. #1071
effectively mandated relative paths only. check if install dir is
relative or absolute and either include ${prefix} in pc file or not
Fixes#1098
Fix issue "CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.".
* remove defaulted constructor
It gets implicitly generated.
Signed-off-by: Rosen Penev <[email protected]>
* default some more
swap is not needed here as shared_ptr is copyable.
Signed-off-by: Rosen Penev <[email protected]>
---------
Signed-off-by: Rosen Penev <[email protected]>
* unused includes
Signed-off-by: Rosen Penev <[email protected]>
* Use consistent order of includes
Always include in the following order:
- Own header files
- Standard header files
- System header files
- Project header files (toolkit first)
Exceptions:
- cppunit/extensions/HelperMacros.h must be included after
header files declaring stream operators
- config.h must be included before its definitions are used
---------
Signed-off-by: Rosen Penev <[email protected]>
Co-authored-by: Urs Fleisch <[email protected]>
Urs Fleisch
Stephen F. BoothandUrs Fleisch
complexlogicandGitHub
complexlogicandUrs Fleisch
Rosen PenevandGitHub
evpobrandUrs Fleisch
Jan PalusandGitHub
