[sane-standard] More device properties

[abel deuring]

m. allan noah wrote:

>> Perhaps not enforced, but encouraged ;) From Eikazo's file Widgets.py:
>>
>>        # grepping the Sane backend sources, the following ways exist
>>        # to select and detect an ADF:
> 
> [snip]
> 
> ok- but i seem to be missing something- _WHY_ does the frontend need
> to know that an adf is in use? that, i think, is the problem that we
> should fix.

A frontend should have the option for an ADF scanner to
automatically start a new scan, when an "old" scan is finished.
OTOH, providing two buttons like "make one scan" and "make repeated
scans" for non-ADF scanners is a bit crazy. In other words, a good
GUI should present a button "repeated scans" only for ADF scanners.

>> ummm, in theory, yes. But in the real world it is quite difficult to
>>  anticipate all possible options that might be used by more than one
>> backend. Just consider how difficult our discussion is, if it makes
>> sense to add an option "adf-side". We have quite different concepts,
>> how many variants of ADFs exist/make sense/can be thought of, and
>> what formal descriptions are required to deal with all possible
>> devices properly. My crystal ball is defunct since a long time, so I
>> don't dare to predict that we will be able to cover today all
>> possible features that may become a standard for scanners produced
>> in five years ;)
> 
> yes- and this is exactly why i resist the standard listing all the
> possible values for an option. It seems ok to suggest a certain
> spelling, or a certain leading text for some options for use with
> translations, but the backend must have the option to extend as
> required.

Translations are indeed a good reason to enocurage the usage of
well-known options.

As I understand Etienne, he is aiming for a set of options (or some
other data provided by a backend) that allow to map userfriendly GUI
options like "prepare for ADF scans of A4 pages" to a proper set of
backend options. And this becomes the more difficult, the more
"option variants" we have.

> yes, sane1 has much longer legs than most software, a tribute to the
> simplicity and usefulness of its design.

...and this should stay so for Sane2. But we can also try to clean
up at least a part of the mess we had with unnecesarily varying
option names and option values in Sane1 backends. While these
options should not be fixed in the standard itself, we can aim for a
sort of procedure or "good practice" or whatever else to prevent an
uncontrolled growth of the number of similar option variants.

As the discussion about useful/required/handy options for ADF
scanners show, this can be quite tiresome and complicated, but I
hope that result is worth the effort.

Abel