[MPlayer-dev-eng] MPlayer G2

[Anders Johansson]

Hi,

> Hi,
> 
> > > As I promised when I announced my leaving of the project maintainership,
> > > I started some new video player project (nearly) from scratch.
> > > For now I call it MPlayer G2 (as generation 2).
> > 
> > How are you planning to design the startup and runtime user control
> > interface for pluggable modules inside the player?
> 
> Actually I didn't think of that yet. I have no idea...
> Any good idea welcomed (but no XML please:))
> 
> For now I'm rtying to encapsulate every neede dinfo into the URL,
> it works for stream layer most time.
> (like dvd://titleno[.chapter-range]:[angle][/device])
> 
> > The reason I am asking is that I have a similar problem in two other
> > projects I am involved in (one software radio project and a VOIP
> > project). My idea is that there isn't any difference between startup
> > and runtime configuration and they should therefore be handled in the
> > same way. One project that does this is ALSA but I couldn't rip out
> > the communication lib cleanly cause the communication went back and
> > forth from kernel to user space. 
> 
> I don't want to overcomplicate this. Maybe a simple struct like our
> config_t now, usable to export any parameters from the libraries for
> the UI. For the runtime configuration changes there will be a control()
> function for each API.
> 

I can not see any difference between startup and runtime
configuration. Personally I would like to have a solution where a
module could be loaded and unloaded during execution and one could
then write applications that interacted with the module loader like
user interfaces, configuration file readers and writes, daemons for
network transparency or command-line switch readers (for Rich), etc. 

This would make it possible to do quite cool things like interactively
designing a configuration using the user interface and then saving
it. Next time one wants to run the application the user interface is
no longer needed (good for impressing on your girlfriend).

The problem is that this approach requires an abstraction where
instances of a module are somehow uniquely identified. Also it must be
possible to handle sub-modules...

> A'rpi / Astral & ESP-team

//Anders