[sane-devel] SANE2 standard revisited: option descriptors and sane_control_option

[Henning Meier-Geinitz]

On Thu, Dec 05, 2002 at 06:09:57PM +0100, Henning Meier-Geinitz wrote:
> http://www.meier-geinitz.de/sane/sane2/

Now for the option dexcriptors and sane_control_option:

| 4.2.9.7 Option Capabilities
http://www.meier-geinitz.de/sane/sane2/0.07/doc011.html#s4.2.9.7

SANE_CAP_ADVANCED 64

| If set, this capability indicates that the option should be considered
| an `advanced user option.'' A frontend typically displays such options
| in a less conspicuous way than regular options (e.g., a command line
| interface may list such options last or a graphical interface may make
| them available in a seperate `advanced settings'' dialog). 

It's currently not defined, what happens, if a group has the
capability SANE_CAP_ADVANCED.

-->

" If set, this capability indicates that the option should be considered
 an `advanced user option.'' If this this capability for a group, all options
 belonging to the group are also advanced, even if they don't set the
 capabilty themselves. A frontend typically displays advanced options..."
 
sane.h defines:
| #define SANE_CAP_ALWAYS_SETTABLE        (1 << 7)

This is not in the standard. Should we add it? The two camera backends
qcam and v4l define it for all the options.

I hope the following is the intended behaviour:

"SANE_CAP_ALWAYS_SETTABLE 128
If set, this capability indicates that the option may be always set, i.e.
also after sane_start was called."

Not sure, if it's needed at all. But if we don't need it, it should be
removed from sane.h.

|4.3.7 sane_control_option
http://www.meier-geinitz.de/sane/sane2/0.07/doc012.html#s4.3.7

| SANE_INFO_RELOAD_OPTIONS 2
| The setting of an option may affect the value or availability of one
| or more other options. When this happens, the SANE backend sets this
| member in *i to indicate that the application should reload all
| options. This member may be set if and only if at least one option
| changed.

We need a way to also change the constraint. E.g. if a transparency
adapter is plugged in, the range for tl-x may change. Or while in
color mode, 8, 12 and 16 bit are possible, in gray mode only 8 and 16
works.

Proposal:

"SANE_INFO_RELOAD_OPTIONS 2
 The setting of an option may affect the value, the availability or
 the constraint of one or more other options. When this happens, the
 SANE backend sets this member in *i to indicate that the application
 should reload all options. This member may be set if and only if at
 least one option changed. "


An additional proposal, that was mentioned by Major Andras:

Cite:
> In sane_control_option(), the info passed back in *i should allow the
> backend to ask for the preview to become invalid. I think this would
> be useful for backends which can change something fundamental (like
> exposure) that changes the way the image is scanned. This is not
> essential, it would just make the interface more idiot-proof: a
> frontend could mark the preview as invalid (with a red line through it
> or similar -- not by deleting the preview!) to indicate that the image
> to be scanned will be different from the one in the preview.

> Therefore, how about SANE_INFO_INVALIDATE_PREVIEW ?

I'm not sure, how to define it, however. Which option settings cause a
significant change in the preview? Brightness, gamma?

Proposals welcome :-)

Bye,
  Henning