[MPlayer-G2-dev] Re: Data communication between demuxers and UIs

[D Richard Felker III]

On Thu, Jan 22, 2004 at 12:06:53PM +0200, Fre_ax wrote:
> >> >> what do you mean by bloated exactly?
> >> >
> >> > Dependency on an extra layer which isn't needed.
> >>
> >> I believe its needed for option groups. The command line interface is
> >> JUST another UI with some special needs. If you disagree with this
> >> then you are discriminating other UIs.
> >
> > Good. :)
> > It's not that I want to make things difficult on the gui fans... ;)
> 
> Im no gui fan! :D
> I just see having around 1000(half of them dont even work) channels kinda
> troublesome to handle and group with emacs. ;)

That's what perl is for. :)

> >> This way adding new options can be done by editing just ONE file BTW.
> 
> > Huh? No way. The options can't all be in one file because they belong
> > to different _independent_ modules. Independence of the modules is one
> > of the key goals of g2.
> 
> No, not that way. Each module would of course define their own stuff.
> What i mean is that UIs would just "render" this directory(module) as they
> want.

That's what you misunderstand about modules. They are NOT
single-instance components, but can be loaded many times with
completely independent configuration for use in different places, and
the only thing that distinguishes one instance from another is "where"
it is connected to other modules. Without your playlist/"directory"
system this is entirely the problem of the calling app to handle.
(It's actually fairly simple in the command-line case since the caller
can just pass string config to helper functions without having to
worry about the internals, but for gui or runtime config it's more
complicated.) AFAIK your directory system is not designed to handle
something like this.

> >> > In fact when the config system was first discussed, one of the
> >> > major proposals that caused lots of flames was tightly integrating
> >> > the config system with gui/app/playlist stuff. The final decision
> >> > was to layer the config system, with the basic levels only defining
> >> > data structures and functions for manipulating config, and only
> >> > putting the gui/app stuff on the very top (and totally optional)
> >> > layer.
> >>
> >> Again if you guys think g2s config system is now good, i can just as
> >> well implement this system for playlists only.
> >
> > Yes. Your idea may very well be good for playlists.
> >
> > One obstacle though is storing with your playlist the necessary config
> > to represent the rendering pipeline (audio and video filters, etc.).
> > Depending on how we want to do this, it may affect the generality of
> > your playlist system, and that in turn provides a good reason why the
> > MPlayer core shouldn't depend on the playlist system.
> >
> > For example most players may not care to support multi-file input
> > streams with filters to merge them, so maybe the playlist shouldn't
> > either. It seems to me this sort of feature is mainly useful in an
> > editor/encoder app instead. On the other hand, maybe someone would
> > find it useful. I don't know the answers to all these questions right
> > now, so I'm trying to work on the lower-level stuff that really
> > matters right now so we can defer decisions like this until after the
> > basic code is in place and working.
> 
> Agreed. I see creating new channels can be a problem and thats why i think
> playlists should be allowed to optionally define the representation of this.

Huh? This has nothing to do with what I said.

> I mean if dvb, http and ftp gets implemented this way why wouldnt normal
> filesystem ?

???

> But then again, would it work ?
> That would the command line interface think about this ?

???

> I do think that guis should not be given more than bunch of
> config_t's to represent the outlook of the options.

Sorry, that's simply not possible. They have to be aware of the
structure in which components are connected.

> > On the other hand, since it might be useful sometimes (windowed
> > playback under X only) you could make a curses interface, and then add
> > a terminal-emulator to MPlayer. :))) So MPlayer could run its curses
> > gui inside its own terminal emulator which displays overlaid onto the
> > movie... ;)
> Hehe.
> Yah, im not sure how curses works but as far as i can remember it only allows
> users to set chars at x, y location on screen. So this
> "show-on-screen"-functioncould just as well be function pointer that can be switched when using
> different UIs.

That's not what I mean. I said an actual terminal emulator in MPlayer.

Rich