> > as far as option naming goes, that works, but i would rather have a > > defined group (like 'advanced' does) for just buttons/sensors, > > That may also work.
actually, i will take that back. the 'advanced' options are not in another group, they are a capability. > > and have an additional bit that gets or'd with the other SANE_CAP_*, > > something like SANE_CAP_SENSOR on a SANE_TYPE_BOOL > > Is it really a new capability? A button is a typical read-only bool > option that's setable by the user I think. > you could make a case for the buttons to be represented by an opt with a type = SANE_TYPE_BOOL and cap = SANE_CAP_SOFT_DETECT, unfortunately, the front-end would need to be signalled that this opt had changed. this means the frontend needs to give control to the backend periodically (or the backend needs to run a sep. thread, and signal the frontend) best way that i can see a backend to tell a frontend that this is the case is to add a cap. > Well, maybe add a flag like "auto-poll". That would be a new > capability. But keep in mind that new capabilities are SANE2-only > while new options can easily be added to SANE1 also. i find that somewhat strange. a new cap out beyond bit 7 of the existing cap bitmap should not screw up any frontends, right? i am all for inter-operability, but that would seem to be the point of such a large bitmap... > > A possible extensio would also be a "reread value before scan" > capability. not bad, but not good enough for my needs, since what we are really talking about is a front-end being activated into some action by the backend. > > Both are not really capabilities but something like demands, however. > requirements is a good word... > > this enables a front-end to ignore this group of fields (or just show them > > as little fake leds or something) or ask the user which ones they care > > about. > > If the frontend knows about the new options it can use any special > handling it wants. If it doesn't, it shows the options just as normal > read-only bool options. So I don't see any problem here. This > detection is possible with all three ways we have discussed (special > option name, group or capability). > ok, i'll give you that one, other than i have a dislike for encoding data in a string, when the cap is for that very purpose. > > it also allows the backend to give them nice names, that aren't > > preceded with any 'magic' strings of text. > > These names are not presented to the user anyway so I don't think it's > a problem at all to use scanner-button- (or whatever). Using fixed > option names follows the "tradition" of well-known options. > even in scanimage, the name is not displayed to the user? i like using well-known names, but doing string comparisons on the beginning of a name sounds like a need for a flag to me, hence the suggestion of using a cap. > You can still use any title you like for the button by using the > "title" and add a help text in the "description". > > > the fujitsus often have a single digit lcd panel on the scanner, and a > > wheel that the user can use to increas or decrease the reading on that > > lcd. when they press the scan button, the digit on the lcd is also > > transmitted. this could be handled the same way, with cap SANE_CAP_SENSOR > > set on a SANE_TYPE_INT perhaps. > > As you say the transfer of that number only happens when pressing the > button. So either the backend should set SANE_INFO_RELOAD_OPTIONS when > the button status is read and place the number in some read only > option or just handle the number internally (brightness?). What I want > to say: this panel is different from buttons as cahnging the numbers > doesn't start an action on the computer itsself. For reading such data > from the scanner we already have read-only options. That's the reason > why they exist :-) ok, i will agree with that. but just what is going to cause the frontend to call sane_control_option on our button, so that we can set SANE_INFO_RELOAD_OPTIONS on the return? boy, my head is spinning... allan > > Bye, > Henning > > -- "so don't tell us it can't be done, putting down what you don't know. money isn't our god, integrity will free our souls" - Max Cavalera
