Re: designing a wrapper lib



On Wed, 2002-09-18 at 20:43, Jorn Baayen wrote:
> Hi,
> 
> Assuming everyone agrees we need to use one wrapper library for all
> gnome core apps, I want to start up a brainstorming session on what we
> want to have in the lib (let's just call it gmedialib for now, to avoid
> any references to either mm or gstplay). When we have a list of things
> we need we all agree on, we should start to design an API, implement it,
> and push it as new standard lib.
> 
> Please, if you disagree we need to use one single library, reply and
> discuss why you think we need multiple. (We're talking about the core
> desktop lib here, we definetely need an embedding lib (gstplay?) as
> well, but that's not what gnome-multimedia is about, IMHO).
> 
> To start with, here are a few things I could think of. If you think they
> dont belong here, just start a discussion.
> 
> - simple audio/video playback
> - gapless transition/crossfading (Not sure about this one, at least RB
> will need it, but i can imagine other apps needing it. It's just a very
> nice feature that would ideally Just Work on any mediaplayer.)
> - relative volume
> - equalizer backend, perhaps a widget as well?
> - visualization
> - good audio cd support (with things like eject and cd availability
> signals as well)
> - metadata reading and writing
> - internet radio support

Jorn, you're designing an app.

Allow me to make this little analogy (with flaws, as with all analogies,
but you'll get the point).

pretend: GStreamer~=GDK/GTK

What you're designing is a set of custom widgets/dialogs for, say, your
'mail reader' app and hope to have that other, say, 'newsgroup reader
app' reuse as many of the dialogs as possible, which is fine... I'm not
interested in another mail reader, I want to make a, say, spreadsheet
app. Are you forcing me to use your lib with dialogs? 

What I'm saying is that Gtk/Gdk is equally lowlevel as GStreamer yet we
don't build many applications solely around libraries of GtkWindows.

Are you saying that my (one of my mid-term goals) VirtualDub clone
should use that single library of yours? I can give you some of my
requirements then... Are you also saying that my (one of my long-term
goals) NLE library should use that single library of yours too? 

GStreamer is the lowest common denominator between multimedia apps, be
open to that fact that all generalisations have limited scope (player
lib, monkey-media, NLE lib, gst-record, dj turntables, RT guitar
effects,...). 

I don't believe in the one-library-for-everything approach. I do believe
in simple _play_URI type of APIs for people that just want to play a
sound/video, whatever. The mixing/crossfading thing is too limited in
scope, nobody other than RB is going to use that. The other requirements
are RB requirements IMO, or are you suggesting we create N apps to play
and mix a collection of mp3s?

This discussion is turning into a debate of what other multimedia
applications RB should assimilate in a lib, instead of focusing on what
the requirements are for multimedia in GNOME.

my list of provided mm services in GNOME: (short term)

 - cd-player (run and forget, it just plays the damn cd)
 - mp3/ogg/.. player on steroids with mixing, visualisation, playlists,
   etc.. and no, I don't want all my mp3 ID3 tags parsed in my playlist
   and the mixing stuff and vis plugins and the gconf keys for default
   audio device and relative stream volume and the equalizer and the
   metadata editing stuff when I just want to play my cd or do a beep.
 - play_URI type of lib for apps to use (think instructional
   video/audio track)
 - app to quickly preview any type of media you throw at it (based on
   the play_uri API), embedable, bonoboized, scriptable but simple. 
 
long term:

 - mm authoring app (NLE for audio/video, transcoder, tag/metadata
editor, targets include cd/dvd burner, ...)

My 2 cents,

Wim



> 
> Cheers
> Jorn
> 
> _______________________________________________
> gnome-multimedia mailing list
> gnome-multimedia gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-multimedia
> 






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]