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

[Fre_ax]

>> >> 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.
Aha.

>> >> > 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 agree that its too early to say without knowing how lower level works.
Got carried away from the subject. ;)

In order to add new DVB channels with any of the guis one would need to
definethings like name, frequency, polarity, satellite no, symbol rate, vpid, apid.

There are plentty of ways to do this IMHO but id say dynamic config would
stepin at some point.

And no i dont mean just DVB channels but maybe also https user names,
passwords,
ports and maybe other streaming stuff that just cannot be treated as normal
files.

What i mean is that browsing of normal files and playlists could be
implementedwith virtual directories just above each individual gui.

So each gui wouldnt need to use opendir and stuff directly.

>> 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.

I think you misunderstood what i ment.

I mean that each individual gui wouldnt have code like:
// create widget for option x
...
// create widget for option y
...
...
Why ? Because i feel that not all developer would bother adding each new
optionfor all guis. So this might lead to situation where some options are missing
for some guis.

So options would at some level before each gui would turn in to struct that
contains enough information(text entry, check box, ...) in order to make
guis just "render" these options.

I also feel that this would be cleaner and end up with less duplicated code
for each gui.

Sure some options with some guis might "look" better but i think this way
shouldbe considered.

>> > 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.

So users could cd from place to place and use mplayer to play files ?
Like xmms does ? Sounds good to me.

I however think that this should be optional since this would cause
compatibility
problems with windows and possibly other os'es with no terminal emulation.
So why not have both ? :)

--Aapo Tahkola