Re: GtkMediaPlayer widget

[Lee Braiden <jel ntlworld com>]

On Tuesday 16 Dec 2003 6:45 pm, Ryan Gammon wrote:
> Lee Braiden wrote:
> >If we don't decide on a solution, but
> >instead provide abstractions to hedge our bets, all we're doing is adding
> >layers of inefficiency.
>
> I am not proposing another layer or abstraction. I do not want to wrap
> all the functionality of all the media frameworks.
>
> I want to create a clear, consice, simple media player interface that
> media engines could implement. This is not a wrapper. The interface has
> no overhead implications.

Well, simply in terms of a PLAY command... how would you do that?  To me, you 
either use an existing framework directly, including it's enumerations etc, 
or you wrap it, and create a level of abstraction.

For me, the best case scenario is a well-defined, clean API for a multimedia 
framework like gstreamer, and (perhaps) some system in GTK to integrate that 
framework.

Ideally, you would not be telling GTK to play it, but simply asking GTK to 
embed it, and give you a handle for the media framework's object.  Then, you 
use the already well-defined gstreamer API to actually manipulate that 
object, knowing it will work 100% within GTK.

Perhaps I'm missing something, but I can't imagine another way that doesn't 
wrap calls/command codes for PLAY, STOP, etc.  Not if you want it to be 
independant.

Whatever way I look at it, I can't imagine a way to provide a standardised 
GTKMediaWidget that can be implemented by two different frameworks without 
requiring abstraction of some (significant) level.


Again; I can't see the need for this dual-framework approach.  GStreamer is a 
fairly well-established framework, and, as far as I am aware, it provides 
everything needed in terms of codec and hardware abstraction.

All I can imagine is that this is some attempt to establish a Helix-based 
player as a de-facto standard by putting it into GTK first.  Yet I see no 
reason for it to be there at all -- as I understand it, Helix has done it's 
best to avoid implementing its codecs in other players, and so is decidedly 
*against* integration, except INTO Helix players/apps.

As such, I'd again repeat my point that the helix project should, from a 
purely GNOME perspective, be writing codecs (or wrappers for their codecs) 
and apps for gstreamer, rather than an entirely separate framework.

In my opinion, unless you can identify some fundamental flaw in gstreamer that 
needs to be corrected, I see no reason not to consider it *the* GNOME 
framework, and to integrate it tightly.  Whether that is done at GTK level or 
elsewhere is up to the relevant people.

Having said all that, you should probably be aware that I'm not working on 
GTK, and so you don't have to justify yourselves to me, except as a member of 
the community :)

-- 
Lee.