Improving sane-find-scanner

Hi,

I've got a patch (part of which I erroneously committed to
CVS some
time ago...) that makes sane-find-scanner tell the user
which backends
can be used with the USB scanners that it just detected.

It's based on a table generated by sane-desc from the
description
files (really, 2 tables, one for backends included in
sane-backends,
and the other for external backends when we have description
files for
them). The tables eat up some space, so the
sane-find-scanner binary
gets bigger with this patch.

I'm looking for feedback on that idea; I know it's
basically a good
idea and it needed to be done, but the implementation is
pretty
static, which may not please everyone. Probably having a
directory
where external backends can drop a file would be better, so
parsing
the desc files from sane-find-scanner looks like a better
idea (would
just need to generate the tables at runtime from the desc
files, which
would only duplicate some code from sane-desc).

Thoughts ?

JB.

-- 
Julien BLACHE                                   <http://www.jblache.org>
 
<jbjblache.org>                                  GPG
KeyID 0xF5D65169

-- 
sane-devel mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

On Sun, 27 Aug 2006, Julien BLACHE wrote:

> Hi,
>
> I've got a patch (part of which I erroneously
committed to CVS some
> time ago...) that makes sane-find-scanner tell the user
which backends
> can be used with the USB scanners that it just
detected.
>
> It's based on a table generated by sane-desc from the
description
> files (really, 2 tables, one for backends included in
sane-backends,
> and the other for external backends when we have
description files for
> them). The tables eat up some space, so the
sane-find-scanner binary
> gets bigger with this patch.

my only concern there would be if the user sees the name of
an external 
backend, and assumes it is already installed. also- what
about the case 
where a backend is installed, but disabled in dll.conf?

>
> I'm looking for feedback on that idea; I know it's
basically a good
> idea and it needed to be done, but the implementation
is pretty
> static, which may not please everyone. Probably having
a directory
> where external backends can drop a file would be
better, so parsing
> the desc files from sane-find-scanner looks like a
better idea (would
> just need to generate the tables at runtime from the
desc files, which
> would only duplicate some code from sane-desc).
>

are the desc files currently installed anywhere? does it
make more sense 
to roll them up into structs in a .so that we could load?
that reduces the 
runtime processing, while allowing external backends to
provide additional, 
smaller files...

though honestly, i am not all that sure of the benefit. i
mean, if you run 
sane-find-scanner and see it, but scanimage -L does not,
then the backend 
support is missing anyway?

allan

> Thoughts ?
>
> JB.
>
>

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

-- 
sane-devel mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org

"m. allan noah" <anoahpfeiffer.edu> wrote:

Hi,

> my only concern there would be if the user sees the
name of an
> external backend, and assumes it is already installed.
also- what

I clearly distinguished external backends for this purpose


> about the case where a backend is installed, but
disabled in dll.conf?

It's part of the configuration the user will need to do;
she'll have
to edit the backend config file in some cases too.

> are the desc files currently installed anywhere? does
it make more

No, I don't think so.

> sense to roll them up into structs in a .so that we
could load? that
> reduces the runtime processing, while allowing external
backends to
> provide additional, smaller files...

I'm not sure it makes sense, because parsing the desc files
is quite
fast.

> though honestly, i am not all that sure of the benefit.
i mean, if you
> run sane-find-scanner and see it, but scanimage -L does
not, then the
> backend support is missing anyway?

It's one more hint for the user -- if scanimage doesn't
find the
scanner, having the backend name is a good starting point to
find out
what's wrong (usually, the backend isn't enabled).

sane-find-scanner is usually the first tool that is run when
plugging
in a new scanner; just thought it could help to have a
somewhat more
knowledgeable sane-find-scanner.

JB.

-- 
Julien BLACHE                                   <http://www.jblache.org>
 
<jbjblache.org>                                  GPG
KeyID 0xF5D65169

-- 
sane-devel mailing list: sane-devellists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-d
evel
Unsubscribe: Send mail with subject "unsubscribe
your_password"
             to sane-devel-requestlists.alioth.debian.org