[sane-devel] Film holder control (and adf)

[Henning Meier-Geinitz]

Hi,

On Mon, Jan 28, 2002 at 09:29:43AM +0000, Jose Paulo Moitinho de Almeida wrote:
> If I understand correctly the summary is:
> 
> - use dev->sane.type = "film scanner";

Ok. I will add a comment to the TODO list.

> - suggest to the frontends adding a button-type option "Query 
> scan-information from scanner";

I haven't testet but it should be possible to do this with a normal
SANE option. E.g. with the pnm backend there is a similar button.
Setting "reload_options" should work with such a button.

> - the options allow the backend to recognise what the scanner can do;

The backend provides the options that describes the hardware, e.g.
"frame" with a suitable constraint (e.g. 1-6). I don't know if this
works, but in theory... Then the user can select which frame to use.
There can be also a bool option to automatically jump to the next frame
after a scan.

If the frontend should do special things it's better to standardize
these options ("well known options"). However, I'm not convinced yet
why this is necessary.

> - prepare for sane2 a way to automatically inform the frontend that it should 
> reload its options;

Already noted.

> Perhaps another suggestion for the future ....
> 
> - add a flag to each option which informs wether it may change. This is set 
> by the backend who (theoretically) knows the hardware. For the frontend it is 
> only necessary to query those options.
>
> In my mind I have/had a distinction between hardware properties (eg the 
> resolution, which implies a range of options that will not change) and let me 
> call it "accessories" (eg an aps adaptor, which may change the number of 
> images when the cassette is changed or may even be removed without notice). 

A similar thing is already in the SANE standard: SANE_CAP_HARD_SELECT
in commbination with SANE_CAP_SOFT_DETECT. I have never tried it, however.
If this isn't sufficient I'm open for proposals for SANE2.

> Just to further explain my idea those "accessories", when queried, would be 
> described by the backend using a description string, which could be read by 
> the user or parsed by the frontend. 

If the user or the frontend must be informed about a change of a newly
added accesory, this can be done by removing the capability
"SANE_CAP_INACTIVE" from such an option in my opinion. If this doesn't
work, the bug should be fixed :-) If it's the same accessory but with
a different size (e.g. number of frames), changing the constraints
should be enough.

> I understand that this corresponds to a move from the normal sane way of 
> handling options and may be undesirable.
> 
> It is quite possible to work without making the distinction and, as I write 
> this down, I recognise that the border may be fuzzy at times. 

The basic SANE principle is (IMHO): Do all the hardware-specific
things in the backend. Describe everything the hardware can do by
options. Let the user use these options (via a frontend). The frontend
shouldn't know too much about what the options really do because
othewise the frontend must be changed for every new device. Some well
known options are desireable, e.g. for geometry settings in a window
and gamma settings. But we shouldn't go too far in my opinion.

I don't see why this shouldn't also work with film scanners.

Bye,
  Henning