[gst-devel] guadec results
in7y118 at public.uni-hamburg.de
Fri Apr 12 03:09:02 CEST 2002
On Wed, 10 Apr 2002, Thomas Vander Stichele wrote:
> f) We kinda sort of agreed on starting to write a kde gstreamer media
> player as well. From a political point of view this makes heaps of sense.
> We never quite connected with kde media developers at all, and it would
> make good sense to put the pressure on them by way of the users of kde.
> We just need someone to do it of course.
Some thoughts about this.
1) We should separate backend and frontend in the player, just like every
good app (beatbox :) does. So it shouldn't be too hard to write a player
- We don't even have a gtk player and it is so much more important to have
a working player in GNOME than something to demonstrate for KDE.
- I was planning to have a lot of custom Gtk widgets (like the
GstVideoWidget) to make integrating gst stuff into apps easy. These
elements would all have to be done for KDE, too.
- If we are going to store configuration in GConf, making bonobo stuff
(like Nautilus views) and other GNOME-specific things, we will have to
redo that too for KDE.
So it would result in a lot of "porting" for those, who implemented the
player in the end.
I don't think we should even start to consider this at the current shape
the player is in.
> h) We need to focus on getting in a few basic stuff REAL soon now. One of
> these is events. Company, please share your views in a document
> explaining your current views so that we can all understand how it's
> supposed to work and help you and wtay out with sanity checking. This is
> an ESSENTIAL bit for the player and we need to get a player out soon.
> Another thing I think should go in soon is clocking. I have some ideas
> for a subtitle plugin to test the clocking, because it's probably
> something very simple to do.
> I'm guessing the event stuff is so complex we might as well start putting
> code for it in - it doesn't break other stuff too much, I suppose, if we
> get it fixed - and maybe redo it later after the 0.5.0.
The problem with the event stuff is not in the frontend (API), which is
pretty much done/unchanged, but in the backend (handling/scheduling of
events, implementing in the plugins).
Since Application developers aren't supposed to even know about events
(events are inter-plugin communication) the API for apps shouldn't change
at all or just include additions like gst_element_seek, but it's not going
to break source compatibility with apps.
It's definitely going to cause some havoc inside the plugins (and probably
the schedulers, too), but nobody but us is using that API atm.
And I'm about to write some docs. I'll mail to the list when I have some.
I'm currently sorting things in my head so I know what I'm writing about.
So it's easier to understand for you (and me).
More information about the gstreamer-devel