[sane-devel] Simplified installation procedure for Redhat Fedora Linux 1.0 and Epson 1670 scanner, also a report of a bug?

[m. allan noah]

> > 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