This commit adds `_if_some()` variants for builder field setters.
The variants aim at improving usability when setting optional fields.
E.g. currently, we need to write something like:
```rust
let opt_value = ...;
let mut sb = gst::Structure::builder("test")
.field("mandatory_field", "mandatory");
if let Some(value) = opt_value
sb = sb.field("optional_field", value);
}
let s = sb.build();
```
With `_if_some()`, this can be written like this:
```rust
let opt_value = ...;
let s = gst::Structure::builder("test")
.field("mandatory_field", "mandatory")
.field_if_some("optional_field", opt_value)
.build();
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/1424>
These assertions can only trigger because of bugs in the bindings
implementation or in the C code and not because of bugs in calling code,
so using debug assertions is perfectly fine for them and reduces the
number of assertions inlined everywhere in release builds.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/1188>
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
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).
Also separate the lower/upper bound in the name with an underscore. This
cannot be added between `Range` and the first number, that's violating
`non_camel_case_types`.
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 should be analogous to C struct initalizers where all unspecified
fields are initialized to zero. Without mut this reads a bit nicer as
well.
Note that two out of three structs have all members specified, hence
need no zero-initialization of the remainder at all.
This function was named wrong before 1.20, and its return transfer type
changed from none to full. To provide
Note that, when 1.20 Gir files are imported, this `version` override in
gstreamer-video/Gir.toml wil come into effect and create a Display trait
for us (without version constraint). At that point the manual Display
impl should be removed, but the manual to_string implementation remains.
