[MPlayer-dev-eng] A new little feature, and lirc without fork

[Alban Bedel]

Hi Arpi,

on Thu, 24 Oct 2002 00:15:21 +0200 you wrote:

> > we could either
> > - force libmpdemux users to implement at least a dummy function for this
> >   (always returning false)
> implemented.
> your code moved to libinput, where it belongs to, imho
Ok, that's fine for me.

> > > I hope to have a first patch ready in the next days for the first
> > > step. I must said that i'm a bit afraid in touching this config stuff
> > > again but it relly need a big cleanup :(
> > 
> > then left it as-is. the config part works, the playtree part is messy but we
> > used to it already.
I wust really make a few points clearer. The system is split in 3 parts :

1/ The config (m_config_t) : it main role is to manage a stack of context. That is
	each time a new context is pushed it save the option's and restore them
	on pop. It can also be used to set/query the options.
2/ The playtree (play_tree_t) : this is 100% inactif. It only store the playlist and the
	various options setting attached to each entry.
3/ The playtree iter (play_tree_iter_t) : this is the active part. It need a playtree and
	a config. Then it go through the tree using the config to setup mplayer according
	to what is stored in the playtree struct.

You'll notice that there is no parser there. It's the problem that I try to solve. Currently
the parser (cfg and cmd line) are both in the config. But the command line parser need
to build a play_tree_t struct from the command line thus the inter-dependence
m_config_t <-> play_tree_t . Beside this the config code is a whole mess and make it
very hard add new kind of option type or write a new parser (as it's needed for
mencoder). So I'm attemptting to solve this by rewriting the config stuff in a modular
way (so we could easily add complex type like time range). And then write the
parsers in separated compile unit. If it's successful I could then write a cmd line
parser suited for mencoder (as it should behave a bit differently).

> i've killed the unneeded m_config_register_*() calls, without messing too
> much with the globals - i didn't moved all out, and even the ones i touch
> were already globals with a few exception in the demuxer core.
> 
> i don't say that the m_config_* _concept_ is wrong, it's ok, but the current
> implementation was useless.
> just look at the network.c file before and after my today commit.
> you had 1 page of code per variable to get its value - while the variable
> was declared at the beginnning of the file. i mean that http user/pass and
> cache size.
Yes, I'll hope to solve this by saving all options on each push and not only the one
that have been set. So this whole get/set mess will be useless there.

> hey, we are not xine, we don't have to introduce many pages of useless
> overcomplicated oop-style code when there are much simpler and cleaner
> solutions. if you have a subconfig struct somewhere, just export it, instead
> of adding a new struct with pointer to subconfig, and a function which
> callbacks with the address of the pointer-keeper struct and then a middle
> func which calls this function...  just export the first pointer and add the
> reference to the main config struct. isn't it simpler?
> 
I agree with you that it could have been done in a much simpler way for the current
case. But there is still a problem, the host app have to know all options at compile
time. No big deal for mplayer, but in another app that mean that you have to update
your app for every option change in the lib :(
I would rather go for a middle point solution. Export 1 config array with all options
of the lib. So the register take place in mplayer, and other app always have an
up-to-date list of all avaible options.

	Albeu