[MPlayer-G2-dev] Re: module_list vs. gui
albeu at free.fr
Sat Aug 16 11:21:20 CEST 2003
on Tue, 12 Aug 2003 20:27:47 +0200 you wrote:
> 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
> 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
> - enumeration func: a function which returns a single module at a call,
> 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
> or NULL (when we list all modules)
> type: some type value, like 0=static(builtin modules), 1=dinamic
> (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.
Everything is controlled by a small evil group
to which, unfortunately, no one we know belongs.
More information about the MPlayer-G2-dev