Model names (was: [sane-devel] Proposed timetable for the release
Wed, 6 Jul 2005 11:57:54 +0200 (CEST)
many thanks for the detailed information.
I need it very much to reject all those wishes for a
full automagic hardware setup which come up again and again
by the "usability experts" ;-))
On Jul 6 10:02 Olaf Meeuwissen wrote (shortened):
> Johannes Meixner <email@example.com> writes:
> > As scanner config tools build the model lists from the *.desc files
> > it leads to some user confusion which exact model he should select.
> Such scanner config tools put an awful lot of faith in files that in
> most situations are updated manually and bear no direct mechanical
> correspondence to the sources for the backend. I know that such a
> correspondence will be hard to establish but anyway.
I do not trust these files.
Therefore I didn't implement an automated scanner setup.
The user must select the model from a list.
But I build the list from the *.desc files because I don't know
a better method.
I preselect a model in the list if the autodetected model name
is equivalent to exactly one model name in the list.
"Preselect" means that the list entry is marked (highlighted)
as selected but nevertheless the whole list is shown so that
the user can see and select any other list entry.
"Equivalent" means: I convert both the autodetected model name
and the model name in the list to lower characters and remove
all characters except "abcdefghijklmnopqrstuvwxyz0123456789+".
If the resulting strings are the same, the autodetected model name
and the model name in the list are "equivalent".
If more list entries (i.e. more backends) match, I don't preselect
because too many users accept blindly anything what is preselect
but I let the user select the model (i.e. the backend) manually.
But if the model name in one *.desc file is equivalent but not
in another *.desc file because of slightly different model names,
I may preselect it even if it is in fact supported by two
backends (or if it is marked as "unsupported" in one *.desc
but not in the other).
> > The user may think that one model is only supported by one backend
> > because of sightly different model names.
> Actually, I've seen the reverse. Oh, the Perfection 1650 is supported
> by the epson and epkowa backends. Cool! I'll go buy the 1670. That
> should work. Well, it doesn't.
> BTW, the 1670 is supported by the snapscan backend.
As the 1670 is well documented in epkowa.desc and snapscan.desc,
there should be no problem.
But this shows that it is important to have even "unsupported" models
listed (like the 1670 in epkowa.desc) so that the user is informed.
And the example shows that consistent model names for same models
in different *.desc files are important because on the one hand
slightly different model numbers can make a big difference
but on the other hand other minor differences don't make
a real difference - how should a normal user understand this
without consistent model names.
> > I would apprecialte it if at least the manufacturer and model
> > strings in epson.desc and epkowa.desc would be the same and
> > if possible exactly those which are autodetected.
> The first part of your request can be done. It just needs a bit of
> synchronisation between the files. (Karl, are you listening? CC'd
> you explicitly, so I'd say yes. Want a diff against epson.desc?)
> The second part is plain impossible.
I don't think it is "plain impossible".
I think it is possible but requires enhanced *.desc files
(model autodetection strings must be added to the *.desc files)
and a lot of additional work.
The question is whether a "full automagic hardware setup" is
what normal users really must have?
Up to now I don't have one single user complaint because he
must select his model from a list.
> Why all the different names? These scanners are all marketed in
> different regions (something that I also try to explain in a comment
> in epkowa.desc). Not only are the model names different, but quite
> often the imprint on the panel differs as well. Then there may also
> be minor differences in what Windows/Mac software comes with it. None
> of these differences have anything to do with getting the thing to
> work with SANE, but, well, someone thinks there's a need to keep them
> apart somehow.
> # And drive you and me nuts in the meantime ;-)
If all the different names are listed in the *.desc file
it is perfectly o.k. because all what a normal user want
is that he finds his model in the list.
If there are too many same models with slightly different names,
something like "ACME FunScanner 12xx series" is also perfectly o.k.
provided that there are no exceptions (e.g. if "ACME FunScanner 123L"
doesn't work the same as the rest of "ACME FunScanner 12xx series").
> The epkowa backend bends over backwards to try to figure out a model
> name that corresponds to what is on the case
Of course it is the backend which knows best about all its
models and all the special cases, remember the discussion e.g.:
(and the whole big thread)
> Hope this clarifies things a bit. If you do think up a way to improve
> this situation (that doesn't involve a web-cam pointed at the scanner
> ;-) I'd like to know.
Simply list all existing model names in the epkowa.desc file
and add comments which models are in fact the same hardware
so that for example the authors of the epson or snapscan backends
can add model names in a consistent way to epson.desc or snapscan.desc
when models are also supported by the epson or snapscan backend.
> While writing this up, I wondered if a :same-as or :clone-of tag in
> the description files might be useful for cases like this. Oh, and
> while at it, how about a :license tag so we can easily flag non-free
> software (like part of the epkowa backend :-().
And a :firmware tag when a backend requires special manual setup
for firmware upload like the snapscan backed (but not if the backend
does firmware upload full automagically like epkowa does).
SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: firstname.lastname@example.org
90409 Nuernberg, Germany WWW: http://www.suse.de/