[sane-devel] GUI for sane configuration

[Henning Meier-Geinitz]

Hi,

On Tue, Apr 16, 2002 at 10:55:39PM +0200, Christian Fughe wrote:
> I suggest to add more options to the './configure ... and Makefile.in'
> scripts to make the knowledge of the wizards available to the wide area of
> general users as well as for generating a personal configuration.

Examples? Do you mean something like
`./configure --net-hosts="some.server.domain"'?

> When I try new software, it became pretty standard for me to have a look
> at the output of './configure --help' and the files INSTALL and README.
> I do expect all information in these three sources to get the new software
> compiled, installed, and running within a short time. 

In my opinion, we shouldn't mix installation and run-time
configuration. After runnning ./configure ; make ; make install; SANE
runs, that means e.g. scanimage calls all the SANE backends.

Everything else is run-time configuration. That's why I moved that
part of documentation from INSTALL to man sane. You shouldn't need
anything from INSTALL if you used a distribution's package management
system.

If you miss something in INSTALL that belongs to that file, feel free
to cry on this list :-)

> I think it is a
> good idea, that the common commands for installation
> 
> ./configure  ...
> make
> make install
> 
> do everything under the sun for sane too. I look at the sane-backends as a
> kind of drivers. Once a new pice of hardware with the appropriate driver
> is integrated and configured I expect the driver not to ask more
> questions.

The idea of SANE is that you don't need to call ./configure again when
you install a different device.

That's why we always install all drivers and don't have
"--with-backends=mustek" in configure.

I think it's up to the distribution maintainers to provide a GUI or
script that asks you questions about your configuration. They know
their configuration (operating system, device files, libraries,
permissions), we don't.

It's up to the SANE people to make configuration as easy as possible:

* auto-configuration where possible; this works for most SCSI and
  USB scanners on Linux
* providing good defaults and easy configuration for other systems
  (e.g. setting a symlink instead of editing 3 files)
* providing good documentation
* expressive error messages if something goes wrong ("permission
  problem while accessing /dev/sg1" instead of "invalid argument"

Bye,
  Henning