[sane-devel] Interactive use of scanner buttons

[Paul Wolneykien]

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

> >   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).
> >  
> 
> right, the poller acts as a pass-thru, acts as a front-end when
> talking to the backend, and acts as a backend when talking to a
> front-end. We don't have exclusive access problems because the
> applications make a chain.
> 
> >   Emit events to be handled (how?) by the frontends? Doesn't this
> > really would make things harder for frontends?  
> 
> No, we could use your proposed mechanism, but we don't have to change
> backends to support it.

  Aah, a chain! That's possible, I hope. (However, I have a question to
Wilhelm about that.)

  But the backend-aware approach (i.e. making modifications in those
backends, which their maintainers want to support dynamic
notifications) has the following advantage: it's become possible to use
other technics than polling if the hardware supports that. Another
advantage is the explicit use of SANE_CAP_DYNAMIC only for those
options that are expected to be changed by the scanner's hardware (or
firmware). Only the backend author(s) could know such details.

  What is great, is that both approaches (the proxy and a
backend modification) do not contradict each other! If we will add
SANE_CAP_DYNAMIC and SANE_ACTION_SUBSCRIBE to the API we would have two
choices: to handle them in the backend or to handle them in the proxy.

  The backend way I've described earlier: the backend explicitly marks
the dynamic options with SANE_CAP_DYNAMIC and is ready to setup
callbacks if the frontend asks for that by passing SANE_ACTION_SUBSCRIBE
to sane_control_options().

  As to the polling proxy, it seems that it could read a config file
where we can define a set of options that should be polled (along with
the interval). By default, all SANE_TYPE_BUTTON options could be polled.
  Then, the proxy should modify (!) the option descriptor that is
returned by the backend adding SANE_CAP_DYNAMIC to the configured
options (or to all SANE_TYPE_BUTTON options).
  The frontend would then see those SANE_CAP_DYNAMIC options and call
to subscribe the on-change callback for them. But those
SANE_ACTION_SUBSCRIBE calls should be handled by the proxy, not by the
backend! Leaving the backend completely unaware of what's going on.

  What isn't good with proxy approach, is that configuration file.
Ideally, there should be a separate config file for each scanner model!
Why? Because, some dynamic options aren't buttons --- that's for sure.
I have a 7-segment display on my Avision FB2280E which is defined as
SANE_TYPE_STRING. And who can/should provide these configuration files?
Who knows the details? The true answer is --- the backend author
(maintainer). And if so, why not to go a little step further and to
implement handling of SANE_CAP_DYNAMIC+SANE_ACTION_SUBSCRIBE in the
backend?

  Finally, I have a question to Wilhelm Meier, the author of scanbd:
Why does it open and close the scanner instead of polling through saned
from the very beginning? May be our vision of proxy is wrong?


  P.S. Can we get something without even a frontend modifications?
I think, yes, with some another desktop proxy. A desktop proxy could
transform option notifications into some kind of virtual keyboard
keystrokes or shortcuts. If there is a key code for the "Play/stop"
"multimedia" key, then isn't there a key code for "Scan" key?
Or that could be simple Ctrl+F? assigned to a scan action in the GUI
frontend. (Besides, are hotkeys supported in XSane?)

  What's isn't good again, is another config file! The desktop proxy
needs to be configured for each particular frontend in order to
simulate the right keyboard events.

  So, a pure proxy system would be very hard to configure.