It doesn't have to be unused in GTK. A GtkMediaPlayer widget subclass could be provided for animated gifs via gdk-pixbuf and a spinner widget similar to what epiphany/nautilus/galeon uses could also be a subclass of GtkMediaPlayer. Seems like a reasonable enough idea to me. On Mon, 2003-12-15 at 12:36, Ryan Gammon wrote: > 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 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). -- Bob Smith <bob thestuff net>
Attachment:
signature.asc
Description: This is a digitally signed message part