[gst-devel] GtkMediaPlayer widget

Ryan Gammon rgammon at real.com
Mon Dec 15 13:46:01 CET 2003


Ronald Bultje wrote:

>On Fri, 2003-12-12 at 20:36, Ryan Gammon wrote:
>  
>
>>1. Gtk has a documentation page with a gtk-prefixed interface for a 
>>basic video widget, and a list of links to engines that implement that 
>>interface, and maybe a "which engine is right for me" document.
>>    
>>
>
>But that doesn't need Gtk. What you're looking for is a widget lookup
>page. That doesn't need integrating in the core desktop toolkit. ;).
>  
>

The question here is not one of needing something from gtk so much as 
making something easier in gtk.

Technically, all gtk really needs to offer is a GtkWidget base class. 
Buttons, labels, entry boxes, etc. *could* all be implemented outside of 
gtk, with different prefixes for each of these controls to indicate 
which project they're coming from. Realistically, rounding up and 
integrating all those widgets would suck, so gtk ships a wide variety of 
widgets to make things easier for developers.

What's being proposed here is adding a GtkMediaPlayer widget base class 
to gtk. When I say base class, I mean a .h file for the interface, and a 
.c file that implements gobject support, but is otherwise unimplemented. 
This would not give gtk a dependancy on, for example, a sound server.

You would be unable to instantiate this GtkMediaPlayer widget directly. 
Like a GtkBin, there would be no gtk_media_player_new function. It would 
serve only as an interface to other toolkits that wanted to implement it.

This would solve two problems: A technical problem, and a non-technical 
problem.

=== The technical problem ===

A number of people are interested in gtk video/media widgets, be they 
part of helix, gst, totem, a front to a bonobo control, etc. It would be 
great to have basic interoperability at a  play/stop/pause level. Eg, 
you could have code like this:

GtkWidget *player;
player = hx_player_new(); /* or bacon_video_widget_new() */
gtk_media_player_play(GTK_MEDIA_PLAYER(player)); /* Simple, 
interoperable call */
hx_player_set_eq_reverb(HX_PLAYER(player)); /* Advanced call */


=== The (more interesting) non-technical problem ===

A developer wanting to add a media widget to his or her application 
today is going to have a terrible time.

1. They may not know they want a media widget
A developer today might need to add a flashy front-end to his or her 
application, and use gtk for the back-end dialogs, etc. It may be 
possible to do this with a variety of gtk_* calls, theming, etc. but it 
is probably easier to do with a SMIL presentation.

The SMIL alternative is unlikely to occur to a casual gtk developer 
today -- it is not obvious from the gtk documentation that media widgets 
are available and can be used with gtk.

Having a video widget interface in the core documentation would make 
more developers consider using a media framework like helix in their 
application. This would be good for everyone interested in gnome multimedia.

2. Gtk developers may want a video widget, but not know where to get one.
Having a GtkMediaPlayer interface has implications on documentation.
- It provides a logical place to put information regarding available 
media widgets in the core gtk documentation.
- It provides an incentive for books, tutorials, etc. to talk about gtk 
media widgets, since they are now a core part of gtk.
- The GtkMediaPlayer api would emphasize that the basic functionality of 
media widgets is easy to use.

What do you guys think?

(I'm subscribed to gtk-devel-list, gnome-multimedia, and 
dev at player.hc.org among others -- if people feel these lists are better 
for this topic, feel free to follow up to those instead of the gnome lists).

-- 
Ryan Gammon
rgammon at real.com
Developer for Helix Player
https://player.helixcommunity.org






More information about the gstreamer-devel mailing list