After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 141692 - gst_init() type function that ignores arguments it doesn't understand
gst_init() type function that ignores arguments it doesn't understand
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: 0.8.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-05-03 01:38 UTC by Tim-Philipp Müller
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tim-Philipp Müller 2004-05-03 01:38:31 UTC
There should be a gst_init() type function that works like gtk_init(), ie. 
that strips out and parses the --gst-* arguments and just ignores all the 
others. 
 
(Personally, I think GStreamer should drop its libpopt dependency altogether, 
but I have a feeling that is not too popular an option). 
 
Cheers 
 -Tim
Comment 1 Ronald Bultje 2004-05-03 14:02:10 UTC
How should it work? How do we know if the argument requires an argument or not?
So --my-funky-arg --gst-fatal-warnings: is --gst-fatal-warnings an argument for
--my-funky-arg or not?

It's impossible, or at least hard. Use popt and gst_init_get_popt_tables().
Comment 2 Tim-Philipp Müller 2004-05-03 14:24:21 UTC
Granted, it's impossible to get perfectly right. 
 
However, gtk_init() and friends don't care too much about that, and it's also 
reasonable to say  
 
  "the extremely rare case where '--gst-fatal-warnings' is a possible  
   argument to your '--my-funky-arg', you'll just have to use it like 
   '--my-funky-arg=--gst-fatal-warnings' or filter it out before you call 
   gst_init()". 
 
gst_init() is not as convenient to use as it should be, and it's inconsistent 
with gfoo_init() usage elsewhere, IMHO.  
 
Cheers 
 -Tim 
 
 
 
Comment 3 David Schleef 2004-05-03 17:37:40 UTC
This is obviously something that's not going to be fixed while we're API stable.
Comment 4 Thomas Vander Stichele 2004-07-06 11:29:11 UTC
Actually, Johan fixed this after 0.8.3.  I don't see why it can't be fixed in
API stable, since it is more permissive, not less.