Re: Gnome Video Player - WAS:Re: A baggage-free approach to gnome-media

[Dennis Smit <synap yourbase nl>]

On Wed, 2002-09-18 at 22:24, Thomas Vander Stichele wrote:
> Hey Dennis,
>
> > Maybe you shouldn't see monkey-media just as a wrapper, but as a higher
> > level library which covers the low level bits of gstreamer and more than
> > just that.It allows one to be flexible but also shields one from how the
> > pipelines are laid.
> 
> That's true.  Monkey-Media is good at that.  However, it does present an 
> extra step in abstraction, which sometimes make things harder too.  It's 
> fully GObject-ized, which is nice, but hard to follow since I find myself 
> jumping from one virtual function to another.  I'm not saying that's bad, 
> it just means that it's a complicated library to hack on.  That's not a 
> problem, since it does really well what it was designed to do - support 
> rhythmbox.

Well i don't mean this wrong but the code is really clean i did a
few bug fixes without any knowledge of the code and now i am working
on adding visualization support without any real problem but besides
from that. Also it isn't only designed to only support rhythmbox anyway
i am not going to argue on that AGAIN :).
 
> If monkey-media would evolve to a more general GStreamer wrapper (which it 
> can, we just need to work out how, if we want that), it will definately 
> need a lot more features.

And so Jorn asked for a list of features that should be in it :).
Also features are added in a very rapid speed. Visualization,
Radio and CDrom stuff is all added right now.

> What I mean by that is
> a) monkey-media is very good for rhythmbox at this point
> b) monkey-media isn't very close to what a gnome developer currently needs 
> from a multimedia API.   It allows you to play mp3 and ogg files using
> a few objects, but that's it. (There's nothing wrong with that btw !)
> c) Monkey-media currently has an API where you need
> to create stream and mixer objects, connect to an eos callback, go to the 
> main loop, and set the state to playing.  The "simple" case (playing a 
> sound) takes about as much code as the equivalent GStreamer code.

Well i agree on this one. The monkey-media api might even be to
powerful for simpler cases.. Any suggestions how we can solve this
without taking away the 'flexiblity' ?

> 3) is a problem.  The sample command-line player is indeed short, but 
> should be shorter for a gnome developer.  It's about just as long as a 
> gstreamer app that plays the audio.

Again suggestions how we should solve this without taking away some 
flexiblity ?

> > Also it actually does matter if monkey-media is between or not. Think
> > about it like this: monkey-media can be for gstreamer what gtk is for
> > gdk. Simpler development.
> 
> Actually, if you look at the analogy, it's more like this :
> 
> (GStreamer internals)	Gdk
> GStreamer		Gtk
> gst-plugins		gtk widgets
> gst-editor		glade
> gnonlin			one of the extended gnome API's

Hmms well you could see it like his but even then gstreamer is very
lowlevel and the comparisation wasn't about that. It was to distinct 
the difference between very low level and high level.

> I agree that code duplication is not a very good idea.  That doesn't mean 
> there needs to be, we just need to find sets of features that are 
> orthogonal.  It's pretty certain that RhythmBox will always have needs 
> that are specific to RhythmBox.  Think about it - if all of the features 
> that RhythmBox would need were all in this one library, then the only 
> thing you can decently write with that library are RhythmBox clones.

Well i don't agree on that monkey-media only allows RhythmBox clones
seen it's just multimedia playback so you can go into every direction.
All the features RB need is playback, ripping, visualization and
tag editing and i really THINK that more apps want to use such 
features. As in it isn't bad to have an nice library for this.

> It is very likely that there is some middle ground where some common 
> functions can be abstracted away, but it is also likely that some 
> functions will be rhythmbox-specific.
 
Could you give me an example of what features would be only RB specific.

> > Another thing i read or heard at irc the last few days is that a few
> > people think that monkey-media is bloat. Well if you think that
> > monkey-media is bloat for media application what do you think off 
> > gstreamer being ? 
> 
> I don't think it's bloat.  It's not easy to code in, because it has a high 
> abstraction level, but it's not bloat.
> Neither is GStreamer, btw - it can be as thin as you want and you can run 
> it embedded as well.  Bloat is a matter of perception, and most people 
> that complain about bloat can be easily uncovered to be not very 
> knowledgeable on the subject.
> 
> Compare to me saying that bonobo is bloat.  I don't even know what bonobo 
> really is on the inside ;)

It's funny because you were this person suggesting that monkey-media
is kinda bloaty, anyway i personally think that neither monkey-media
or gstreamer are bloat in anyway. Where gstreamer allows the extreme
powerful flexiblity monkey-media adds a layer for application
programmers. (Not for a do_a_beep_when_i_click_here) application. 
This is a whole different thing since these aren't multi media
applications but applications which are supported with sound
notifications. No as far as i know monkey-media isn't focusing
at those.

> 
> > there was something about the mixer that only
> > rhythmbox needs it. I think not. I can imagine that there are more
> > applications that would like to use cross fading or volume 
> > normalization. but if you don't agree proof me wrong.
> 
> Simple gnome apps won't need it.  I can imagine other apps that do, and 
> I'm probably going to write one or two myself for various other projects.  
> When I do, chances are high that I will make it depend on whatever 
> monkey-media evolves into, since that's what it was designed for.

Well see it like this. Simple gnome apps won't need bonobo either.
But it's there for those who do (maybe a somewhat stupid comparisation
*heh*).

Cheers,
Dennis