[gst-devel] GtkMediaPlayer widget
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
=== 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:
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).
rgammon at real.com
Developer for Helix Player
More information about the gstreamer-devel