Re: GtkMediaPlayer widget



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



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