Re: Re: Data communication between demuxers and UIs

On Fri, Jan 23, 2004 at 10:25:15AM +0200, Fre_ax wrote:
> >> > 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. ;)

Yeah.

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

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

> > 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 however think that this should be optional since this would cause
> compatibility
> problems with windows and possibly other os'es with no terminal emulation.

Obviously.


Rich