[gst-devel] new API for applications to check plugin requirements

Tim Müller t.i.m at zen.co.uk
Wed Oct 12 01:32:46 CEST 2005


On Wed, 2005-10-12 at 09:32 +0200, Stefan Kost wrote:

> I see the need to check if plugins are available and probably if they are recent 
> enough. But from the users perspective getting such an error dialog wont be very 
> useful. The user wont know what to do to fix the problem.

That's as much as an application can do IMHO, and it's still much better
than failing unexpectedly or being buggy in subtle ways. 

If, say, thoggen pops up a dialog at startup that says 'Thoggen needs
the following GStreamer plugins, but they are not installed: theoraenc,
oggmux, and this plugin is outdated, please upgrad it: dvdreadsrc' then
at least the user knows immediately that something is wrong and he needs
to do something before he can continue.

The alternative in this case would be to let the user set everything up,
select titles, select encoding parameters, etc. etc., only to fail in
the third dialog when the encoding begins, after the user has already
spent 10 minutes doing stuff that's not going to work in the first
place. Or hit a known bug after 5 hours of encoding.

In another scenario, the application developer just KNOWS that some
plugin before version 0.X.Y is buggy and shouldn't be used. In that
case, it makes sense to check the version of the plugin at startup. 


> IMHO the app need to make sure at build time that the required plugins
> are available. Can you elaborate why that wont suite your needs?

There should be configure checks as well, yes, but configure checks are
simply not enough, even if they also check plugin versions. The reason
configure checks are not enough is that they require packagers to
tediously track the plugins requirements (+ version requirements) and
keep those in sync with their package dependencies. That's just not
going to work in the real world, at least not for applications that
aren't "important" applications.

So as an application develop I don't want to rely on the package
dependencies to be correct, and GStreamer packages might get upgraded,
downgraded, mixed, you name it. Of course we can just blame it on bad
packaging, bad dependencies, bad user behaviour, bad whatever, but that
just doesn't solve the problem for the application developer.

This is not some hypothetical case. I've run into this with thoggen, and
thoggen is really a fairly simple application.


To cut a long story short: I think API like that is required to make
GStreamer software more user-friendly and catch obvious installation
problems from the start.

 Cheers
  -Tim







More information about the gstreamer-devel mailing list