Relax AppSrc::connect_need_data() callback bounds

Currently callback in AppSrc::connect_need_data() requires Fn(&AppSrc, u32) + Send + Sync + 'static, while in AppSrcCallbacks::builder().need_data() only FnMut(&AppSrc, u32) + Send + 'static.

Also FnMut() should be applicable in Aggregator::connect_samples_selected() and probably other similar signals.

changed milestone to %0.17.0

@nazar-pc What's the use-case for this btw? Why wouldn't you use the callbacks? :)

I'm wondering if I should just remove all these signals from the bindings as they're less convenient to use and considerably slower.

The use case is to render video frames in a part of pipeline that looks like appsrc ! queue ! compositor ! .... Every time need-data is fired, new frame is generated. However, the "renderer" has internal state that needs to be shared between calls.

I'd say AppSrc::connect_need_data() is trivial to discover after reading gst-inspect output, but I didn't know AppSrcCallbacks builder exists until I read examples in this repo. Also set_callbacks wasn't very obvious as to what it does (especially due to absence of documentation on methods) as if it was, let's say, set_signal_callbacks.

The fact that there is any performance difference is also news to me, but I do see that gst_app_src_set_callbacks docs mention that, would be nice to have that in a more visible place I guess.

Which docs were you looking at? https://gstreamer.pages.freedesktop.org/gstreamer-rs/git/docs/gstreamer_app/struct.AppSrc.html#method.set_callbacks has the same text as the C function, for example.

The docs say that it's less flexible but I'm not sure what that is referring to. The only difference functionality-wise that I can see is that with signals you could have multiple signal handlers... but why/when would that make sense?

I meant docs in Rust code on methods themselves. IDE has nothing to work with and even when you click the link to open docs it leads to docs.rs (I'm talking about IntelliJ in this case). Ideally docs should be embedded into the source code itself and built on docs.rs, otherwise discoverability suffers a lot.

Ah. That's unfortunately not possible because the docs are LGPL licensed, and you probably don't want to go through all the trouble that statically linking proprietary code to LGPL code involves :)

Yeah I'm also not very happy about this situation. It was a silly idea to release the docs under the same license as the code, but who would've known 20 years ago :(

mentioned in commit slomo/gstreamer-rs@4254b3d5

mentioned in commit slomo/gstreamer-rs@62c20dbe

mentioned in commit slomo/gstreamer-rs@f2491740

mentioned in commit slomo/gstreamer-rs@04e6c1b5

closed with commit 04e6c1b5