Hi, On Mon, Feb 09, 2004 at 03:25:33PM -0500, m. allan noah wrote: > sure. but we might still be a ways off from sane2.
It's just a set of options so they can be used with SANE1 without any trouble. > also, i dont feel like > the proposal gives enough detail about just what each bit of the button > bitmap does, or which ones actually exist in the scanner. if the backend > could spec names for each bit, then you would not have some > trial-and-error to get your front-end to do the right thing on each button > press. We could at least define some standard buttons (scan, mail etc.). E.g. #define SANE_BUTTON_SCAN (1 << 0) #define SANE_BUTTON_MAIL (1 << 1) #define SANE_BUTTON_FAX (1 << 2) [...] If you want custom descriptions, it won't work that way. What about this proposal: -------------------- "scanner-buttons-lock" is of type SANE_TYPE_BOOL, default = SANE_FALSE As before. For locking and unlocking the buttons (I don't think it's needed but that's a long discussion and there a pros and cons on both sides). The backend must make sure that only one frontend has access to the scanner buttons of one scanner at the same time. "scanner-button-*" e.g. "scanner-button-scan" of type SANE_BOOL is a read-only option. If the lock is not active, SANE_STATUS_ACCESS_DENIED is returned. Otherwise, if the button is pressed currently (or has been pressed since the last read of this option) the value is SANE_TRUE. Otherwise SANE_FALSE. The title of the option is the name of the button: E.g. "Scan". The frontend should poll this option about once per second. Several of these options can be defined. All options which names start with "scanner-button-" are scanner button options. --------------------- Anything I'm missing here? Bye, Henning
