[sane-devel] Interactive use of scanner buttons

Paul Wolneykien manowar at altlinux.org
Fri Dec 3 16:39:36 GMT 2021


В Fri, 3 Dec 2021 11:08:23 -0500
"m. allan noah" <kitno455 at gmail.com> пишет:

> On Fri, Dec 3, 2021 at 9:33 AM Paul Wolneykien <manowar at altlinux.org>
> wrote:
> 
> > В Fri, 3 Dec 2021 09:02:43 -0500
> > "m. allan noah" <kitno455 at gmail.com> пишет:
> >  
> > > Many backends are single threaded currently, so this would be a
> > > pretty invasive change.  
> >
> >   But that's not a required change, isn't it? If a backend isn't
> > ready for it, it just should not add SANE_CAP_DYNAMIC to the
> > options. 
> 
> That makes things hard for front-end developers, because of the
> variation between backends. This will negate one of the strengths of
> sane (few frontends supporting lots of backends).
> 
> I wonder if there is another approach here- middleware? Similar to how
> backends are unaware that they are being used over the network with
> saned, perhaps we could have a kind of intermediary poller, which ran
> on the machine with the scanner? It could emit events, and not
> require all backends which support buttons to be updated?

  As far as I know, SANE provides exclusive access to the scanner for
one client only. So, we can run a poller or a frontend, but not both.
That's why I would like to see the polling process running "inside"
backend (be launched from the backend as a thread).

  Emit events to be handled (how?) by the frontends? Doesn't this
really would make things harder for frontends?

  And again: I don't want to require any backend to support
notification features. The same for the frontends. All what I propose
is the use of two additional constant values, indicating new type of
capability and a new type of action --- thanks to the completely
abstract sane_get_option_descriptor() and sane_control_option() design.



More information about the sane-devel mailing list