[sane-devel] Sane API

[Jürgen Mellinger]

Specifying a gamma value for acquired scan data would greatly add to usability as well.

—Jürgen

> Am 12.10.2020 um 20:00 schrieb Ralph Little <skelband at gmail.com>:
> 
> Hi,
> 
> On 2020-10-12 2:06 a.m., Olaf Meeuwissen wrote:
>> Hi Ralph,
>> 
>> Ralph Little writes:
>> 
>>> I would be interested to participate.
>> You're welcome but I'm not sure how we want to go about things.  A lot
>> has changed since the bulk of that version 2 draft was written.  From
>> what I've seen of the changes (during the conversion from LaTeX to
>> Sphinx), they look sensible but I feel there is a lot more that ought
>> to be updated for the 2000-twenties.
>> 
> My main motivation is related to my experience in using a few different
> devices now and some common usability themes have emerged for me:
> 
> 1) Often scanners spend a lot of time in calibration and it isn't always
> that obvious mechanically or audibly that that is what is going on. It
> would be cool if a frontend could emit some kind of status update to
> reassure the user that something is actually going on. We don't have
> anything in the current spec to support that.
> 
> 2) Backends have different ideas about what is "advanced" and what is
> basic which just looks a bit messy. It would be good to establish some
> guidelines on some of the more common options. I'm thinking the x/y, w/h
> type options primarily.
> 
> 3) We talked a bit ago about polling options and it would be good to get
> something more formal to deal with this. Just as a reminder, there was a
> machine with a "copy count" display indicator that the user could
> increment/decrement with buttons next to the display. We can now display
> the content of that window but since the value of this is "volatile" and
> could be conceptually linked to the scan count in the frontend (e.g.
> xsane), there is no way to indicate that the frontend should regularly
> poll for the value. Obviously there are frontend issues regarding the
> conceptual linkage and there was some concern about idly polling over
> the network as a form of DDOS attack, but I think that some thought
> might be put into a backend solution to support that capability.
> 
> There are probably some other things that are not coming immediately to
> mind.
> 
> I actually really love the simplicity of the current API and I would
> hate to complicate things much if at all. I also appreciate that
> whatever happens, the NET protocol has to support it.
> 
> As regards the issue of backwards compatibility, that is a serious
> concern since many of the machines cannot be easily regression tested.
> However, if we could expand the scope of the number of officially
> recognised "options", then that might work for much of what I have
> listed above.
> 
> Cheers,
> Ralph
> 
>