Rob Shortt wrote:
> Yes, I was feeling wierd about that too. How about using an object
> oriented / inheritence approach as Kans suggested? TVSettings(),
> DVBSettings(), IVTVSettings(), each with apropriate properties.
Agreed.
>
>> TV_SETTINGS['dvb0'] = TVSettings()
>> This will auto-configure the TVSettings:
>> - set mode to dvb
>> - set device to adapter0
>> So TV_SETTINGS needs to be much more than a simple dict. But the
>> interface should be like the one you propose.
>>
>>>TV_SETTINGS['tv0'].vdev = '/dev/video1'
>>># Or maybe their second tuner is on video2
>>>TV_SETTINGS['tv1'].vdev = '/dev/video2'
>> We can auto-detect this (more or less). Should we support /dev/video1
>> for tv0? Or do we also prefer /dev/videoX for tvX?
>
> How about we not use tv/ivtv/dvb and use tvX/ivtvX/dvbX. tv0 should
> start at /dev/video0, etc. Maybe we can do something like
> TVSettings('tv', 0) or ('tv0') or TVSettings(0), DVBSettings(0),
> IVTVSettings(0).
Do not add the 0 in the constructor, this looks to complicated:
TV_SETTINGS['tv0'] = TVSettings()
TV_SETTINGS is no real dict, on __set_item__ it auto sets the device
to 0 because the user adds it to 'tv0'.
Or even better, we auto detect all this and user only sets a new adev
if needed by typing
TV_SETTINGS['tv0'].adev = '/dev/dsp'
Dischi
--
According to Kentucky state law, every person must take a bath at least
once a year.
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
