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
