From: Siggi L. <si...@us...> - 2002-06-28 19:58:25
|
Hi Ewald, On Fri, 28 Jun 2002, Ewald Snel wrote: > xine_t *xine_init (char *vo_id, int visual_id, char *ao_id, > xine_config_values_t *config); > > [...] > > Although perhaps not directly related to xine, this API change will make the > xine arts plugin for KDE (which uses special audio and video output plugins) > impossible. :( How exactly does this break the arts plugin? Couldn't hey simply do something like xine = xine_init("special-arts-video-plugin", "special-arts-audio-plugin, ...); IOW: (Why) Is it necessary to initialize xine with plugin pointers instead of having xine load the special plugins? There is a reason for this change: the new plugin loader needs to store plugin directories somewhere (read: somewhere in xine_t) before it can efficiently load any plugins. So you need a xine_t, before you can load any plugin. This could, however be solved by splittin xine_init similar to this: /* * create a new xine_t instance * * note that you can only use this to access config values or load plugins * before you have initialized it via xine_init() */ xine_t *new_xine(void); /* * initialize a newly created xine_t, making it ready for playback * * returns: 0 on success, or an error code on errors */ int xine_init(xine_t *xine, vo_driver_t *vo, ao_driver_t *ao); However, this blows up the interface a bit, so I'd avoit it if possible... Cheers, Siggi |