in7y118 at public.uni-hamburg.de
Tue Apr 16 05:23:03 CEST 2002
On Tue, 16 Apr 2002, Thomas Vander Stichele wrote:
> While doing that I was wondering what exactly the goal of the gst-player
> module is. Before it had been stated that the main app should be really
> short (which it is, it's pretty sadly short actually ;) ) and the player
> lib should be generic enough so that for example KDE could reuse it (maybe
> I misunderstood that, that's just the idea I have of it now).
My idea of the player was that it has infrastructure handy to include
sound/video easily in every program, especially GNOME programs.
This should include:
- Support for creating pipelines automagically when given a stream or
file. GstPlay is such a thing.
- Support for playing short sounds (like "you've got mail" or "ping" when
an alert dialog pops up) that are kept in memory and played with a simple
- a lot of Gtk Widgets to support all kinds of stuff. This should include
a videowidget (we have at least a proof of concept), a playlist widget, a
simple player widget (play, pause, stop) and something like the ActiveX
movie control from windows.
- some programs using that stuff. Ideas are the media player, a nautilus
music view, applets, bonobo, mozilla plugin, whatever.
- I'd like to have a complete player in GStreamer. If people work on an
application inside our project, I feel that the feedback for core
stuff from those app developers would be much better, faster and more
constructive. And other app developers had code to look at on how things
But this requires some people to develop such a media player.
> Well, at the moment the lib is not like that, of course. I can see the
> merit in splitting it up in a generic part and a gtk part, but in essence
> if we want to do that, I guess we should do it the right way and start
> from the ground up, because the player has had so many reorganizations
> that it's just build- and codecrufty from the ground up.
I'd like to call the player stuff "all the glue that is needed to let apps
easily use GStreamer". Every sophisticated project would use other ways to
access GStreamer, but Nautilus or the panel or whatever should use this.
> ATM I don't really know how to add i18n support since the main app doesn't
> contain strings, they're all in the lib, but i18n requires you to call a
> few functions and stuff like that as well (as far as I can make out
> anyway). I'm going to look into it further though.
Well, Gtk+ supports i18n, so we should, too. IMO even the core should do
More information about the gstreamer-devel