[MPlayer-G2-dev] g2 config - restart...

Arpi arpi at thot.banki.hu
Wed May 14 14:37:11 CEST 2003


Hi,

> 
> > Hi,
> > 
> To be short I agree completly with everything up to layer 3.

hmm, i'm surprised :)

> > layer 3
> > =======
> > 
> > it will handle high-level parsing, ie reading/writting config files,
> > multi-file (config/playtree?) commandline configuration.
> > it could be used as a base of both CLI and GUI players, while the CLI
> > oen may have input (key/mouse/etc) events joined to some config
> > variables, while the gui will have sliders and comboboces for this, but
> > the startup(building the config struct chain, filled by the defaults and
> > overwritten from configfile) and at exit write it back to configfile.
> > 
> > i still have some doubts and unclear things about details, esp. about
> > what level of conftrol we may allow here (it will require the ability to
> > laod specified plugings to check their config structs)
> 
> Yeah layer 3 is bit more tricky. That is we come to a point where the
> app and the lib 'meet each other' so to say. The advantage of such
> layer is that various apps could use some common config files for
> example. It would also make things a lot easyer for loozy/lazy coders.
> On the other hand some will want xml config file, other simple plain
> text and so on and so on.
> As you clearly defined the taks of the other layers, the layer 3 could
> be some kind of sample/default implementation on how to use the config

of course!
actually the whole g2 is build with layer independency in mind, so any
app can left out layers or replace them with its own implementation.
it's especially true for the config layer.

for a GUI-only app it's enough to use cfg layer 0, and it may use its 
_own_ xml-based config parser and whatever to handle the options...

> API. I think that having this part of the G2 lib is needed as a lot of
> ppl don't want/need to write their own. But it should be simple for
> an app to use its own stuff at this level.
> Now imho such sample implementation should be quiet simple so i vote
> for a playlist and not a playtree. Most of you would probably second
> that ;)

agree


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu



More information about the MPlayer-G2-dev mailing list