No subject

cancelled immediately in this case. I don't think it's forbidden to
call sane_read again but the backend shouldn't depend on that. 

>  c) The above behavior would give everything an overall consistent behavior:
>       1) An image acquisition cycle begins when sane_start() is called.
>       2) An image acquisition cycle ends if sane_start() returns a value
>           which is not SANE_STATUS_GOOD, or when sane_read() returns a
>           value which is not SANE_STATUS_GOOD.
>     In this model, one must call sane_read() one last time to finish the
>     scan, and that is when any file descriptors should be cleaned up.
> 
>     But this conflicts with the requirement that sane_cancel() be called
>     at the end of a scan.  It seems to me that sane_cancel() is actually
>     being overloaded; it shouldn't serve as both a post-scan clean-up
>     function and as the 'stop now' signalling function.

Maybe we should use "sane_end" or a similar function for the normal
end of a scan.

>     (Someone will say enforcing such a model would break almost all of
>     the current backends.  Oh well, maybe for version 2.0....)

That's definitely 2.0 stuff.

>     If sane_read() or sane_start() return SANE_STATUS_CANCELLED, does 
>     sane_cancel() *still* need to be called?  The strict reading of the
>     specification would say "yes".

As far as I understand the standard, it's only necessary to call
sane_cancel once. The scan is finished immediately or in the case of
an interrupted function, at the end of that function. 

If the backend returns SANE_STATUS_CANCELLED without a previous call
to sane_cancel I guess it's just not complient to the standard.
 
>  d) Anyhow, all that aside, it seems to me that if select() is waiting
>      on a file descriptor fd, then it is bad asynchronous behavior for
>      a call to sane_cancel() in a signal handler to close that fd.
>      (Presumably the fd is connected to a pipe connecting to a reader
>      process spawned by the backend.  The far-end of that pipe should
>      be closed, causing the select() to see a pending EOF on the fd.)

Maybe, but that's not in the standard :-)

>     However, select() should return an EINTR if it is hit by a signal,
>      and calling select() again should then return EBADF if the fd is
>      gone....

I think I tried that once and that worked.

>  e) Maybe using the "IOChannel" facilities of GDK instead of gdk_input
>      would work better?  (Just looked at the manpages; seems to be able
>      to do stuff in the case of other error conditions.)

No idea.

>  f) There are *no* return codes listed for sane_get_parameters().
>     One of the possible return values should be SANE_STATUS_CANCELLED,
>      in case the scan has been cancelled between the sane_start() and
>      the sane_get_parameters() calls.

As sane_get_parameters can be called before sane_start, I don't think
that this is correct. 

> I say make the current behavior explicit:
> 
>  a) If an option group is tagged with SANE_CAP_ADVANCED, then all of the
>      options within it are considered advanced options, and the frontend
>      should display, or not display, the whole group depending on the user's
>      preference.
>     The constituent options in the group inherit the ADVANCED tag from the
>      group, and it does not matter whether they have the tag or not.
> 
>  b) If an option group is _not_ tagged with SANE_CAP_ADVANCED, then the
>      options within it may individually be tagged as ADVANCED options, and
>      the frontend should display them as such.

I will probably add that to doc/backend-writing.txt as it's more a
hint on how to display options.


Bye,
  Henning