There are different implementations and signatures for `get_pollfd` depending
on whether the target platform is unix or windows. When generating the doc,
we need both implementations to appear regardless of the target platform. This
commit is inspired by the way Rust `std` library deals with `process::Command`
OS dependent variants
(https://doc.rust-lang.org/std/process/struct.Command.html#impl-CommandExt).
Documentation can't be accurate though as we can't use the`std::os::windows`
on `unix` and vice versa. As a workaround a fake fd class matching the other
platform is declared.
This could be further enhanced once `#[doc(cfg(...))]` is stabilized
(https://github.com/rust-lang/rust/issues/43781) by declaring `#[doc(cfg(unix))]`
or `#[doc(cfg(windows))]` instead of the hard coded comments `This is supported
on **Windows/Unix** only`. Unfortunately, these comments disappear when
generating will `--all-features` because they are not part of the documentation
in the gir file.
When feature `dox` is selected but not `futures`, the `futures` crate is not
available as a dependency leading to a "can't find crate for `futures`" error.
Allow instantiating and dereferencing concrete queries. The motivation
for this proposal is to allow the following usability enhancements:
- Concrete queries mutability guaranteed by the borrow checker,
including for generic functions:
``` rust
let mut p = Query::new_position(::Format::Time);
p.get_mut_structure().set("check_mut", &true);
```
- Concrete queries functions available in place:
``` rust
let mut q = gst::Query::new_duration(gst::Format::Time);
let duration = if pipeline.query(&mut q) {
Some(q.get_result())
} else {
None
};
```
Concrete events and messages share common attributes which can be factorized in generic builder `struct`s. This reduces noise in the concrete implementations.
Implement `deref` for concrete derivatives of `Event`, `Message` and `Query`. This allows accessing generic methods such as `is_sticky` for events, `get_seqnum` for messages or `is_serialized` for queries and `get_structure` for all.
These methods are commented out in order to maintain consistency between messages with and without arguments. It will be restored and conditioned to feature "v1_14" when GStreamer v1.14 is released.
Building an argument-less message such as eos yields an assertion failure due to the inner structure being null. The short term solution consists in checking that the inner `structure` is not `null` before attempting to insert `other_fields`. The consequence is that `others_fields` defined for argument-less messages will be ignored. A correction will be applied when GStreamer 1.14 is released thank to the introduction of `gst_message_writable_structure` (see https://bugzilla.gnome.org/show_bug.cgi?id=792928). Due to the dependency on GStreamer 1.14, the correction will be only available under the activation of a feature "v1_14".
Events are not affected as the build method the availability of `gst_event_writable_structure` and this function "will never return NULL". However, we can avoid a `structure` allocation for argument-less messages without `other_fields`.
