[Kwintv] Channel format plugins questions

[Dirk Ziegelmeier]

> csv format can be used to export the channel in a format that is the most
> accessible.
> With hand or a script everybody can convert it to any format that is not
> supported by qtvision.
hm... I'd say XML is good enough, since you can also easily convert it but I 
see your point.

> > - I think the channel storage shouldn't be a plugin. We should use XML,
> > it
> I dont see the reason why it shouldn't be a plugin. Plugins are most suited
> for functionality like this.
What does a user with less knowledge do? Hmm, I don't know all this, but 
xawtv/zapping sounds good. If I choose this (just tried it) qtvision always 
looses its channels and reimports the standart channels at startup.
I played around trying to import xawtv or zapping files, but no success.
Maybe I'm too stupid, but can anyone explain how to import xawtv or zapping?
If not, it seems to me that the channel support is completely broken for files 
other than xml and csv. Besides, if I choose csv qtvision saves csv format to 
channels.xml file...

> Channel file import is very important feature. I hope you dont deny that :)
I completely agree! This is why I said we need to have 
Channels->Import->[format list].

> Export is hopefully not that important, but we need to have them to be fair
> with our users...
Sounds good, but let's do it by "Channels->Export->[format list]". This is 
much less confusing and prevents the user from doing wrong choices in the 
channel plugins tab. But I seriously doubt that anybody needs it. And it's a 
pain to maintain since we always have to keep track of what x other TV apps 
do.
Zapping stores much more info for each channel. Does zapping act gracefully if 
we write incomplete config files since we don't have the other properties? In 
all cases?

> If it is really a lot of work, than IMHO you can avoid some of it.
> What is important IMO is to have the csv format export work with all data
> available.
OK, implemented it already.

> For zapping I would say (looking at a zapping config file), that it is not
> possible to parse the device source correctly. So you can ignore it.
OK

> That is: it would be enough to only add read support for xawtv format
> (because it is read only anyway).
Since it doesn't even work (see above) I have no interest in patching the 
format. I can't even try it, and I'm not intrested in the xawtv import, so I 
also don't want to fix the complete plugin.

> And read write support for kwintv. If that is a problem for you than
> hopefully somebody will help you out :)
It is, kwintv (as distributed by SuSE) doesn't work on my box and can't 
compile it from CVS (I don't have the messages available, but I tried some 
weeks ago). And once again, who uses TWO TV apps???

My personal opinion is: Move all formats except XML to the attic until someone 
writes an Import/Export submenu for the channels. The formats should remain 
plugins, but there shouldn't be a channel plugins tab in the config dialog. 
We always read and write XML, and if someone needs it, we import (and 
sometimes export) csv, xawtv, zapping and old kwintv.

George: If you (at least partially) understand my point, please apply my patch 
that makes the source a channel property. I think it can be applied anyways, 
since export doesn't save source and norm, but it didn't up to now anyways. 
Also, import will work since my patch applies the currently selected source 
if the source property is empty.
Unfortunately, this does not happen when the channels are loaded but when they 
are tuned for the first time. I'm not really satisfied with that, but the 
loading channel plugin doesn't have a pointer to qtvision (and I think that 
this is correct, it shouldn't have one) so I can't figure out the current 
source. We should add a "fixup" function after loading that fills in unused 
properties. This will also come in handy if we want to import a format that 
doesn't support all of our features.

Ciao,
Dirk

--
Dirk Ziegelmeier * dirk at ziegelmeier.net * http://www.ziegelmeier.net