-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 18 Jun 2002, Andy Balaam wrote:
>Here's one suggestion: use a Java-style properties file which is
>standard in that every useful line looks like this:
>
>key=value
>
>so e.g. channels are done like:
>channel.1=choice.bbc.co.uk
>channel.2=one.bbc.co.uk
>
>Then any GUI would just have to ask the user for the value of each key.
It wouldn't be much of an interface though - in fact, it would be less
friendly than the text-mode prompting we have at the moment. At least
now the grabber can explain the _meaning_ of each option, and check the
allowable values, and allow the user to select from a list (which is
always better than just typing in text). Also the questions asked don't
have to correspond to the exact format of the configuration file, for
example the particular channel ids are normally hidden from the user,
who just has to recognize the names.
>It doesn't address the issue of how to download the channels though,
>unless the grabber downloaded them itself, which seems silly in the
>extreme.
Huh? The grabber is the only thing that should know about the channels
available.
>Perhaps a hybrid, where the grabber provides a shell of a config file e.g.
>tv_grab_na provides:
>
>---
>retry limit: 2
>retry delay: 30
>zip code:
>provider:
>---
>
>Then the GUI can collect all the required info (but how does it
>validate?)
Also how does it explain to the user what the options mean? OK, these
examples of 'retry limit' are reasonably self-explanatory (to a
technically savvy user) but what about internationalization? We
shouldn't present bits of raw configuration file to the user.
You could have the configuration file contain 'explanations' of what
each option means, what the allowable values are, and different strings
for different languages. But that is adding even more complexity.
I'm sure you can see that what you propose is a general 'configuration
engine' where programs specify what options they have available, and a
single GUI lets you configure these options - without actually knowing
for itself what they mean. That would be an interesting project no
doubt, but I don't think it's the best answer right now.
>Argh it's fiddly. I think maybe there has to be some specific code for
>each grabber's configure step. That code more naturally fits into the
>grabber, but I really don't want the Tk stuff making the download huge.
We'll have to measure that. If you like, it should be possible to built
two executables for each grabber, with and without the graphical
configuration.
>Perhaps just putting a terminal into my program is the best thing to
>do. (and leaving the grabbers how they are)
Three megs extra is less than seven minutes on a 56K modem, and I don't
think the bloat will be quite as bad as that.
- --
Ed Avis <epa98@xxxxxxxxxxxx>
Finger for PGP key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9Dwj1IMp73jhGogoRAlevAJ999Hn9GpkSQiGdCwWYAS16HhyViQCfUBd4
aK23SiQWPhQunWjeqdWRVcs=
=BuRg
-----END PGP SIGNATURE-----
|
