[MPlayer-G2-dev] Re: module_list vs. gui

[Alban Bedel]

Hi Arpi,

on Tue, 12 Aug 2003 20:27:47 +0200 you wrote:

> Hi,
> 
> As I already found it, and tdoay Albeu asked too, there is a problem
> with the current config element type MODULE_LIST.
> The current code uses a function to find modules by name, but it's not
> useful for guis where you want to list the available modules.
> 
> Let's see what are our options:
> - find_module_by_name() (current) - not good for gui (can't list
> modules)- pointer to module_t array - not good for code, there may be
> multiple
>   lists, dinamically loadable modules (and as we discussed earlier, a
>   CLI shouldnt load all those, only the explicitly named modules), and
>   special hidden modules (for internal use, like null or vf_vo2/vf_vd
>   wrappers)
> - enumeration func: a function which returns a single module at a call,
> and
>   can be called until you get null, to get all available modules
>   (you should pass the previous return value (or null at 1st call) as
>   parameter, to make it thread safe / reentrant)
> 
> I would go for a mix of the 1st and 3rd option, ie. an enumeration
> function which can also do searching. Something like the good old
> findfirst/findnext of DOS:
That's sound good to me.
 
> module_t* enum_modules(module_t* prev, char* mod_name, int type)
>   prev: the result of previous call, NULL for 1st call
>   mod_name: name of the module we're searching for (when explicitly
>   named),
>      or NULL (when we list all modules)
>   type: some type value, like 0=static(builtin modules), 1=dinamic
>   -1=internal
>      (note: this field shouldn't be changed between the first and other
>      calls, and implementations may read it only at 1st call)
>      Mayeb it could be flags instead, ie 1, 2, 4, so they can be OR'ed
Flags would make much more sense imho.
	Albeu 
-- 

Everything is controlled by a small evil group
to which, unfortunately, no one we know belongs.