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

[Fre_ax]

>> 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.
>
> Eh? All of these can be treated as normal files in a playlist. They
> all have urls. IMO this can be done very easily for DVB channels too,
> and probably should...then some kind of aliasing/playlist system could
> sit on top for selecting channels.

Hmm. Yeah it should be suitable IMHO.
I think DVB playlists wouldnt even need real playlists as saving this
"playlist"should get done at demuxer level where reading channels.conf currently takes
place.

Implementing opendir, readdir, closedir, mkdir, rmdir ... for urls might just
do it. Or is it done already ? :)<

This should however implemented in a way that ordering of channels in this
playlist/directory
doesnt get mixed up when adding new channels. With linked lists maybe ?
readdir i mean.

>> >> 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.
>
> Arrg RTFmla (mailing list archive). This was discussed about a year
> ago and already done!

Good, good. :D

>> > 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.
>
> No. Do you know what a terminal emulator is?

I believe terminal emulation is done by connecting to /dev/"something" and
thenwriting everything that user types there and displaying everything that comes
out of there, right ?

No i dont know how far you can go with this and what things could be done
withterminal emulation.

With some IPC stuff one could even use dymanic config with command line
interface.
Or what you had in mind ?

What about auto completion for not so GUI-like UIs ?
If there is readdir for urls this could be done for some UIs.

With some IPC stuff in mplayer controlling mplayer via remote login would
also possible. :)

So i think using multiple GUIs or UIs at the same time should be possible at
least
without running in to implementational issues if someone wants to implement
stuff like that.

--Aapo Tahkola