getters/setters are already generated for the `Aggregator` base class
and the property in the subclass is not really needed here. It also
causes problems with trait resolution as the getter/setter functions
will exist twice.
When I introduced the 'ser_de' feature, I couldn't find a way to
name it 'serde' while also make it pull the optional 'serde'
crate together with the other related dependencies.
With rustc >= 1.60 we can use 'dep:serde' to refer to the 'serde'
dependency as part of the 'serde' feature.
warning: deref on an immutable reference
--> gstreamer-audio/src/audio_buffer.rs:255:35
|
255 | Self::Owned(ref b) => &*b,
| ^^^
|
= note: `#[warn(clippy::borrow_deref_ref)]` on by default
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#borrow_deref_ref
AudioCapsBuilder::new() will have the default values for
rate/channels/layout/format. Similarly, VideoCapsBuilder::new() will
have the default values for format/width/height/framerate.
The trait FormattedValue was only implemented on types which
could implement the full range of values for a Format. In order
to declare a function which could take both the intrinsic type
of any Format (e.g. `ClockTime`) as well the full range of values
(e.g. `Option<ClockTime>`), the argument was declared:
```rust
impl Into<GenericFormattedValue>,
```
This commit implements `FormattedValue` for any type representing
a format. E.g.: both `ClockTime` and `Option<ClockTime>` will now
implement `FormattedValue`. The trait `FormattedValueFullRange`
is implemented on types which can be built from any raw value.
These changes are intended to help for the implementation of a
means to enforce format conformity at compilation time for
functions with multiple formatted value arguments.
The following signatures were found to be incorrect and are fixed:
- `message::StepDone`: forced the type for `amount` and `duration`
to be of the same type, when `duration` is expected to be of the
`Time` format.
- `query::Convert::set`: the two arguments were forced to the same
type, so potentialy the same format, unless a
`GenericFormattedValue` was used.
See https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/1059
Represents combinations of flags with a '+' separated string of nicks,
or an empty string for no flags set.
Note that most flag types will ignore any flags using multiple bits when
serializing, since in most cases these flags cover all used bits.
The `links` annotation in `Cargo.toml` is intended to ensure that in the
crate graph there's at most one crate that's an implementation of
some sort concept.
This can make sense in some scenarios, most prominent of which is when
the crate defines `#[no_mangle]` symbols (e.g. by compiling a vendored C
library.) In that situation linking a binary that depends on two
versions of the library cannot work because of colliding symbol names.
There does not appear to be a similar reason to impose such a
restriction on the users of `gstreamer-sys` and similar, however. All of
these crates link to a system library, they do not define any
`#[no_mangle]` symbols nor they vendor and build C libraries as part of
their build process. All they do is linking to a system library. Most
likely all the different versions of the bindings will link to the exact
same library too.
I haven't seen any global resources that these bindings use to ensure
soundness of the library, either.
Now that the crates are generated and linked against v1_20 binaries
there is no need to guard this codepath when building `dox` (which
inherently enables `v1_20` but did previously not actually compile
against that version yet).
This version adds a `--strip-docs` flag to `generator.py`, used in
conjunction with `--strip-docs --embed-docs` to clean documentation
first before re-embedding it (otherwise the same text would show up
multiple times). It is also used in the CI to check that no
documentation disappears on stripping, ie. all documentation is properly
annotated with `// rustdoc-stripper-ignore-next`.
When importing the prelude of a crate like `gst` the `glib` prelude is
provided too. Shedding these imports saves quite a few lines and
adheres to keeping it simple; we're not reexporting base/parent preludes
for no reason :)
For cleanliness the prelude module only needs to reexport preludes from
direct, "top-most" crates, which themselves take care of reexporting
preludes from its dependencies again. This shaves off some code while
maintaining the same set of exports.
In gir it was brought up [1] that some traits (in particular
`*ExtManual`) are exported from the crate root in addition to the
prelude, cluttering the environment unnecessarily. This commit removes
all these reexports, leaving those in prelude (that were already there)
only.
After this commit everything matching `Ext(Manual)?\b` in `lib.rs` sits
within `pub mod prelude {};`.
[1]: https://github.com/gtk-rs/gir/pull/1111
Gir now prints all directories and their hashes in the version file and
comments; useful now that gstreamer-rs is being generated from both
gir-files/ and gst-gir-files/ submodules.
The sys crates have not been generated with 1.20 introspected gir files
yet, and break the documentation that is already compiling with the
v1_20 feature. Function body contents don't truly matter for the
documentation build anyway.
This scales better as there will only be only such data instead of two
or more when having deeper class hierarchies with multiple Rust
elements, and also makes it unnecessary to use a special instance struct
so the default works well.
gir has been fixed to omit all unnecessary imports from objects, enums
and flags which currently are the only offenders of this linter warning.
Hence disallow this warning from now on which is anyway not applied to
every crate - like gstreamer-gl - where such issues have been uncovered.
