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

[Fre_ax]

>> > I see no reason playlists are a "config" item. Rather, a playlist is
>> > a list of sources and configurations for playing them. Some users
>> > of the mplayer-g2 core will want to have playlists, but for others
>> > it makes no sense, or needs to be treated differently, so I'm
>> > opposed to putting all kinds of playlist nonsense into the core.
>> So lets rename it to "data layer" and add seperate directory types
>> for config data
>> and playlists.
>
> Config does NOT fit into nice little directories like you imagine. You
> have little understanding of the config requirements it seems.

Yes im having trouble understanding how adding directories would make
everythingincompatible.

>> > I don't like this whole "directories" thing. It's windowsish,
>> > bloated, and forces a particular system on the caller which won't
>> > be
>> > appropriate for anything but gui players with playlists.
>> True but who says the command line interface would need to open this
>> playlist directory and activate(generate entries in side the
>> directory) this code at all?Of course these directories wouldnt even
>> exist if user wants no guis. So you think its nicer to have tens and
>> tens of options without grouping them atall ?
>
> No, if you'd read any of the previous material on the config layer
> you'd notice that it's all associated with instances of something, not
> horrible globals like in G1.

Good, so g2's config system is now good and capable of taking care of future
needs ?

>> 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.
Dont get me wrong iv seen these media players for linux come and go
so i understand that in mplayer g1 command line interface is superior but
thisis g2 we speak of.
This way adding new options can be done by editing just ONE file BTW.

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

>> Adding new entry type that contains codecs_t or similar structures is
>> no problem.
>>
>> I do agree that its useless to implement this system if both dynamic
>> and static configs(including relevant data communication with these
>> structs) cannot be handled by extending this system.
>
> What on earth is a dynamic config??

Static you mean? Say configuration that cannot take place when playing files.
This of course makes no difference for guis as all configuration can be
considered
to be dynamic.

>> I would however want to remind you that this system solves problems
>> with DVB playlists, dynamic configuration and probably some other
>> things.
>
> It doesn't solve any problem with dynamic configuration. The difficult
> end of dynamic configuration is the other end, the implementation.

I take that back, it implements dynamic configuration.

> As for DVB playlists, WTF is so special about them? How are they
> different than any other playlist?

DVB channels arent real files but rather io calls to kernel land.
This is currently done with libmpdemux/dvb* files in mplayer g1.

Also i would be willing to partly(or entirely) implement curses based mplayer
after/if you get this dynamic config stuff sorted out. Or would it be
better ifthere would be GUI in the playback window ?

--Aapo Tahkola