We were already using `gir -d` and especially now that our files are
separated across two directories that are relative to the directory
containing Gir.toml this only becomes cumbersome. Besides `gir` lacks
functionality to normalize the path, leading to ie.
gstreamer-gl/egl/sys/../../../gir-files in the version comment as a
result.
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 crate was added right around the same date the conversion to the
`lgpl_docs` crate took place in 801998c7 ("Generate documentation from
the docs crate directly") and hence likely missed out.
Fixes: 4120ded4 ("Add gstreamer-controller")
Docs generated using:
./gir/target/release/gir -m doc -c gstreamer-controller/Gir.toml -d gir-files -o unused
Followed by `mv gstreamer-controller/docs/gstreamer-controller docs/`.
The `-o` option is required but ignored in favour of a toml
`doc_target_path` config option.
Quite a few issues slipped in over time because the docs are only
extended with `embed-lgpl-docs` and provided as artifact as part of a
manual action, that isn't clicked often.
Using `.ok()` is more concise when loosing error context in favour of a
simple `None` value.
Automatic replacement SSR pattern in rust-analyzer:
{let $a = $b;match $c {Ok($d) => Some($e), Err(_) => None }} ==>> {$b.ok()}
Note that rust-analyzer does not support:
- duplicate labels (ie. $c should be equal to $a, and $e equal to $d);
- statement lists yet, hence both sides are wrapped in braces.
But it performs the desired operation well enough here.
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.
While this allows to remove the pad probe multiple times, which would
cause a g_warning(), this is not actually making the situation worse
than before while making some code patterns easier to implement:
- Probes could already be removed twice by return
gst::PadProbeReturn::Remove and then calling pad.remove_probe()
- Probes could be removed from a different pad than where they were
added
As such let's go with the simple solution here for now and allow giving
owned access to the probe id from the probe callback.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/issues/286
Otherwise the API of the base classes will be directly available and can
cause confusion (e.g. gst_base_src_set_format() vs. the "format"
property).
All base class API should be considered "protected" from an application
point of view and only be called by the subclass itself.
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/872
Make it an actual bitflags type instead of just an u64 alias and add all
the constants. As it's not defined as bitflags in C this needs to be
done manually.
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.
Parameter mutability has been fixed (and reverted, hence overridden with
const=true)for this function in gstreamer; it can now be automatically
generated.
