infrared, SANE_FRAME_RGBA

On Thursday 14 December 2006 12:11, Alessandro Zummo wrote:
> On Thu, 14 Dec 2006 08:48:38 +0100
> Gerhard Jaeger <gerhardgjaeger.de> wrote:
> 
> > > 
> > >   I would like to add the format
SANE_FRAME_RGBA and have the infrared
> > >  channel passed back as the alpha channel. I
would then patch
> > >  scanimage to save this channel to a tiff
file.
> 
> > sorry for the noise, but AFAIR, we had this
discussion already here
> > about extending the currently available image data
formats. The
> > conclusion was, that with SANE 1.0 we should not
do that - SANE 2.0
> > will be the solution ;) - Henning???
> > 
> > I see that your changes won't probably break
anything, but I think
> > it is again time for the discussion - Allow
extending SANE 1.0
> > or not - SANE 2.0 is far from being ever started
:(
> 
>  I would really appreciate a sane 2, but we have a
problem:

Guess we have much more than one ;)

>  who will write it? who will port the drivers?
> 
>  some drivers are old. original authors are not
available.
>  original testers are neither and they might
>  no more have the equipment. 
> 
>  I've got 0 (zero) answers to my "call for beta
testers" for
>  the epson2 driver.
> 
>  the code must be completely reviewed and each driver
>  has some code/style standard of its own to handle the
things.. 
> 
>  a complete rewrite could take no less than 1 year if
appropriate development
>  forces (and equipment) are available, which it doesn't
seem the case.
>  (there are open bugs in the bug tracking which are
more than
>  3 years old).

Full ACK.

>  And that is when development is started, but first we
should agree
>  on the sane2 specs, which could take months.

It already took us years ;)

>  So we either find a way to pay 2/3 developers full
time or
>  I guess we should stick to sane 1 :-D

he, he...

>  So, my opinion is to stick to sane 1, document what we
have
>  at the deepest level (i'm, for one, adding comments to

>  epson2 in order to explain what's done).
> 
>  we can reorganize the drivers, split the code and
>  add some features (like new frame formats, which
>  are a quite easy thing and would not break anything)
> 
>  maybe add a wiki and a new friendlier bug tracking
>  system (trac has both).

any volunteers?

>  some things that have been agreed on sane2 can easily
>  be implemented in sane1 with no/minor compatibility
>  issues.

ACK.

>  minor tweaks, like agreeing on common names
>  for scan sources are implementable (ADF vs Automatic
Document Feeder).
> 
>  so, while having sane2 is a good thing, IMHO we are
not at a
>  point where this can be done. improving sane1 is still
doable though
>  and would be helpful in the path to sane2.
> 
>  my suggestions, thus, are:
> 
>  - wiki

Hmmm, it's like everything around here in the net:
* a lot of the information is hopelessly outdated
* if up to date, nobody uses it - they ask on the mailing
list

>  - trac
>  - comments

* Good thing, we started usage of doxygen...

>  - dropping support for anything that is not C99
>  - code reorganization (no more 6K lines in a single
file!)
>  - standard debug levels for drivers (no more
SANE_DEBUG_DRIVERNAME)
>  - conformance

The same problem as porting the stuff to SANE 2 - you'll
need the
authors...

>  and call that sane 1.5 

> 
>   just my two cents...

Only two ;)

All of your point sound reasonable and doable for me - of
course, but as I
said: We ran into these discussion often enough and the
result was:
No new features, they are for SANE2.

But I think you are right, we are moving into a dead-end. We
have 
devices that are able to do much more than we are able to
support
with the SANE 1 standard AND we have a not yet finished (if
finished
ever) SANE 2 standard.

I'd like to hear/read some more opinions on that.
Any?

Gerhard





-- 
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 Thu, 14 Dec 2006 13:40:45 +0100
Gerhard Jaeger <gerhardgjaeger.de> wrote:

> >  maybe add a wiki and a new friendlier bug
tracking
> >  system (trac has both).
> 
> any volunteers?

 if someone has a machine, installing trac is easy, and I
can
 eventually do it. I can use a machine at my company, but
would prefer
 to keep it on an "open" sever.


> >  my suggestions, thus, are:
> > 
> >  - wiki
> 
> Hmmm, it's like everything around here in the net:
> * a lot of the information is hopelessly outdated
> * if up to date, nobody uses it - they ask on the
mailing list

 well.. it depends on the community.. I've seen bad
 and good wikis. But we don't know what will happen
 unless we try 

> >  - trac
> >  - comments
> 
> * Good thing, we started usage of doxygen...

 /me hates it 
 
> >  - dropping support for anything that is not C99
> >  - code reorganization (no more 6K lines in a
single file!)
> >  - standard debug levels for drivers (no more
SANE_DEBUG_DRIVERNAME)
> >  - conformance
> 
> The same problem as porting the stuff to SANE 2 -
you'll need the
> authors...

 not for everything... I have some time to reorganize epson2
 and maybe coolscan 2... dropping support for C99 is also
 easy 

 and.. if you break a driver you will surely get complaints
:-D
 
> All of your point sound reasonable and doable for me -
of course, but as I
> said: We ran into these discussion often enough and the
result was:
> No new features, they are for SANE2.

 I'd agree on the principle if it is implementable 

> But I think you are right, we are moving into a
dead-end. We have 
> devices that are able to do much more than we are able
to support
> with the SANE 1 standard AND we have a not yet finished
(if finished
> ever) SANE 2 standard.

 Event if finished, it could take years to code. And given
 that we are in 2007 I think we can wait no more.

> I'd like to hear/read some more opinions on that.
> Any?

 btw..
 I've appreciated your quick response to my email!

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it


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

Hi Gerard and all SANE developers,

Il giorno gio, 14/12/2006 alle 13.40 +0100, Gerhard Jaeger
ha scritto:
[...]
> But I think you are right, we are moving into a
dead-end. We have 
> devices that are able to do much more than we are able
to support
> with the SANE 1 standard AND we have a not yet finished
(if finished
> ever) SANE 2 standard.
> 
> I'd like to hear/read some more opinions on that.
> Any?

I am not an active SANE developer, but I follow the list
since some
year; I tested SANE on many scanners and on a few operating
system
versions; I worked at the italian translation. Lately I
decided to work
more on coolscan2 driver in order to work with Coolscan V
LS-50 ED, so I
requested all documentation to Nikon and I am actually
waiting for it.
Moreover I develop an application that uses scanners on
Windows (via
TWAIN), and MacOSX and Linux (via SANE).

So take my opinion as the less important among SANE
developers opinions.

My impression is that SANE is nice peace of software, but
there are some
incompatibilities among the backends. As an exemple: a
common user
interface (arguments) would be useful to applications that
invoke SANE.

I have to re-read the SANE2 specification. I think it could
be useful in
making it easy to develop backends and to interface with
them. I don't
remember what were pro and cons in previous threads, but I
am in favour
of starting sane2 implementation now since nothing will
change in the
next months.

Some backends will be "ported" to sane2 earlier
than other; maybe others
will never be ported. But I think that sane does not require
a complete
compatibility with sane1. It may be a "different
application".

Bye,
Giuseppe


-- 
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 Thu, 14 Dec 2006, Giuseppe Sacco wrote:

> Hi Gerard and all SANE developers,
>
> Il giorno gio, 14/12/2006 alle 13.40 +0100, Gerhard
Jaeger ha scritto:
> [...]
>> But I think you are right, we are moving into a
dead-end. We have
>> devices that are able to do much more than we are
able to support
>> with the SANE 1 standard AND we have a not yet
finished (if finished
>> ever) SANE 2 standard.
>>
>> I'd like to hear/read some more opinions on that.
>> Any?

i would vote for re-openning the discussion of SANE2, and
begin a project 
to port a limited number of backends forward. use a whole
new SONAME, such 
that sane1 and 2 libs can co-exist for awhile. many backends
will never be 
ported to sane2, because the scanners have not been made in
10+ years, and 
there is no-one to do it.

my personal list of things other folks have mentioned:

1. i hate threading/forking in backends. it makes debugging
a mess, and 
there are plenty of non-interactive uses for sane that dont
need it (the 
single most popular front-end, scanimage, for one  As per
recent 
discussions on this list, any frontend that cares about
non-blocking, has 
already implemented a threading solution to deal with all
the backends 
that block. lets drop the non-blocking functions.

2. network protocol overhaul- this keeps coming up, but i
dont understand 
it fully.

3. stackable/modular compression libs- lots of scanners give
back jpeg as 
their native format, and we usually open it up to a huge
pixmap, just to 
hand to front-end. this is esp. noticable over saned. zlib,
jpeg, what 
else?

4. inconsistent option names and arguments between backends.

5. inconsistent gamma/brightness/contrast implementations
(sanei_gamma 
i have been playing with here)

6. persistent device naming. none of this libusbxx
stuff, i want 
the backend to provide the name, using something like serial
number, 
rather than using the sanei_usb name.

7. inconsistent conf file layouts- i actually would like to
see something 
more like samba.conf, with [sections], etc.

8. inconsistent debug levels. not that big of a deal i
guess. i would 
rather that they were a bitmask instead of a linear
progression.

9. i HATE the frontends changing br-x/y and tl-x/y into
t/b/l/r- i have a 
front-end that takes cli args like scanimage, and i have to
do the same 
option manipulations so that users can use their scanimage
commands in my 
prog. it also means that my back-ends provided help text for
those options 
is not useful.

10. button support. getting better, but not there yet.

comments?

allan

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

On Thu, 14 Dec 2006 15:18:41 -0500 (EST)
"m. allan noah" <anoahpfeiffer.edu> wrote:

> >>
> >> I'd like to hear/read some more opinions on
that.
> >> Any?
> 
> i would vote for re-openning the discussion of SANE2,
and begin a project 
> to port a limited number of backends forward. use a
whole new SONAME, such 
> that sane1 and 2 libs can co-exist for awhile. many
backends will never be 
> ported to sane2, because the scanners have not been
made in 10+ years, and 
> there is no-one to do it.

 I agree, but propose to re-open only after a number of
developers 
 a really interested in writing code.
 
> 4. inconsistent option names and arguments between
backends.
> 5. inconsistent gamma/brightness/contrast
implementations (sanei_gamma 
> i have been playing with here)
> 8. inconsistent debug levels. not that big of a deal i
guess. i would 
> rather that they were a bitmask instead of a linear
progression.

 those 3 items are quite important imho.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Turin, Italy

  http://www.towertech.it


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

Le jeudi 14 décembre 2006 21:18, m. allan noah a écrit :
> On Thu, 14 Dec 2006, Giuseppe Sacco wrote:
> > Hi Gerard and all SANE developers,
> >
> > Il giorno gio, 14/12/2006 alle 13.40 +0100,
Gerhard Jaeger ha scritto:
> > [...]
> >
> >> But I think you are right, we are moving into
a dead-end. We have
> >> devices that are able to do much more than we
are able to support
> >> with the SANE 1 standard AND we have a not yet
finished (if finished
> >> ever) SANE 2 standard.
> >>
> >> I'd like to hear/read some more opinions on
that.
> >> Any?
>
> i would vote for re-openning the discussion of SANE2,
and begin a project
> to port a limited number of backends forward. use a
whole new SONAME, such
> that sane1 and 2 libs can co-exist for awhile. many
backends will never be
> ported to sane2, because the scanners have not been
made in 10+ years, and
> there is no-one to do it.
>
> my personal list of things other folks have mentioned:
>
> 1. i hate threading/forking in backends. it makes
debugging a mess, and
> there are plenty of non-interactive uses for sane that
dont need it (the
> single most popular front-end, scanimage, for one  As per
recent
> discussions on this list, any frontend that cares about
non-blocking, has
> already implemented a threading solution to deal with
all the backends
> that block. lets drop the non-blocking functions.
>
> 2. network protocol overhaul- this keeps coming up, but
i dont understand
> it fully.
>
> 3. stackable/modular compression libs- lots of scanners
give back jpeg as
> their native format, and we usually open it up to a
huge pixmap, just to
> hand to front-end. this is esp. noticable over saned.
zlib, jpeg, what
> else?
>
> 4. inconsistent option names and arguments between
backends.
>
> 5. inconsistent gamma/brightness/contrast
implementations (sanei_gamma
> i have been playing with here)
>
> 6. persistent device naming. none of this libusbxx
stuff, i want
> the backend to provide the name, using something like
serial number,
> rather than using the sanei_usb name.
>
> 7. inconsistent conf file layouts- i actually would
like to see something
> more like samba.conf, with [sections], etc.

	Some months ago, it was thought of exposing configuration
parameters the same 
way the scanning parameters are exposed. That would allow
frontends or other 
tools to configure backends easily. 

>
> 8. inconsistent debug levels. not that big of a deal i
guess. i would
> rather that they were a bitmask instead of a linear
progression.
>
> 9. i HATE the frontends changing br-x/y and tl-x/y into
t/b/l/r- i have a
> front-end that takes cli args like scanimage, and i
have to do the same
> option manipulations so that users can use their
scanimage commands in my
> prog. it also means that my back-ends provided help
text for those options
> is not useful.
>
> 10. button support. getting better, but not there yet.
>
> comments?
>
> allan
>
> --
> "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

Regards,
	Stef

-- 
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 Thursday 14 December 2006 21:18, m. allan noah wrote:
> On Thu, 14 Dec 2006, Giuseppe Sacco wrote:
> 
> > Hi Gerard and all SANE developers,
> >
> > Il giorno gio, 14/12/2006 alle 13.40 +0100,
Gerhard Jaeger ha scritto:
> > [...]
> >> But I think you are right, we are moving into
a dead-end. We have
> >> devices that are able to do much more than we
are able to support
> >> with the SANE 1 standard AND we have a not yet
finished (if finished
> >> ever) SANE 2 standard.
> >>
> >> I'd like to hear/read some more opinions on
that.
> >> Any?
> 
> i would vote for re-openning the discussion of SANE2,
and begin a project 
> to port a limited number of backends forward. use a
whole new SONAME, such 
> that sane1 and 2 libs can co-exist for awhile. many
backends will never be 
> ported to sane2, because the scanners have not been
made in 10+ years, and 
> there is no-one to do it.
> 
> my personal list of things other folks have mentioned:
> 
> 1. i hate threading/forking in backends. it makes
debugging a mess, and 
> there are plenty of non-interactive uses for sane that
dont need it (the 
> single most popular front-end, scanimage, for one  As per
recent 
> discussions on this list, any frontend that cares about
non-blocking, has 
> already implemented a threading solution to deal with
all the backends 
> that block. lets drop the non-blocking functions.

okay - move that responsibility over to the frontends?
Otherwise the 
responsiveness of i.e. XSane will decrease to zero.

> 2. network protocol overhaul- this keeps coming up, but
i dont understand 
> it fully.

No idea about that, but I think there are others around.

> 3. stackable/modular compression libs- lots of scanners
give back jpeg as 
> their native format, and we usually open it up to a
huge pixmap, just to 
> hand to front-end. this is esp. noticable over saned.
zlib, jpeg, what 
> else?

ACK.

> 4. inconsistent option names and arguments between
backends.
> 5. inconsistent gamma/brightness/contrast
implementations (sanei_gamma 
> i have been playing with here)
> 6. persistent device naming. none of this libusbxx
stuff, i want 
> the backend to provide the name, using something like
serial number, 
> rather than using the sanei_usb name.
> 7. inconsistent conf file layouts- i actually would
like to see something 
> more like samba.conf, with [sections], etc.
> 8. inconsistent debug levels. not that big of a deal i
guess. i would 
> rather that they were a bitmask instead of a linear
progression.

Full ACK.

> 9. i HATE the frontends changing br-x/y and tl-x/y into
t/b/l/r- i have a 
> front-end that takes cli args like scanimage, and i
have to do the same 
> option manipulations so that users can use their
scanimage commands in my 
> prog. it also means that my back-ends provided help
text for those options 
> is not useful.
> 
> 10. button support. getting better, but not there yet.

ACK

11. Overhaul build system

- Gerhard


-- 
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 Fri, 15 Dec 2006, Stéphane VOLTZ wrote:

> Le jeudi 14 décembre 2006 21:18, m. allan noah a
écrit :
>> On Thu, 14 Dec 2006, Giuseppe Sacco wrote:
>>> Hi Gerard and all SANE developers,
>>>
>>> Il giorno gio, 14/12/2006 alle 13.40 +0100,
Gerhard Jaeger ha scritto:
>>> [...]
>>>
>>>> But I think you are right, we are moving
into a dead-end. We have
>>>> devices that are able to do much more than
we are able to support
>>>> with the SANE 1 standard AND we have a not
yet finished (if finished
>>>> ever) SANE 2 standard.
>>>>
>>>> I'd like to hear/read some more opinions on
that.
>>>> Any?
>>
>> i would vote for re-openning the discussion of
SANE2, and begin a project
>> to port a limited number of backends forward. use a
whole new SONAME, such
>> that sane1 and 2 libs can co-exist for awhile. many
backends will never be
>> ported to sane2, because the scanners have not been
made in 10+ years, and
>> there is no-one to do it.
>>
>> my personal list of things other folks have
mentioned:
>>
>> 1. i hate threading/forking in backends. it makes
debugging a mess, and
>> there are plenty of non-interactive uses for sane
that dont need it (the
>> single most popular front-end, scanimage, for one
 As
per recent
>> discussions on this list, any frontend that cares
about non-blocking, has
>> already implemented a threading solution to deal
with all the backends
>> that block. lets drop the non-blocking functions.
>>
>> 2. network protocol overhaul- this keeps coming up,
but i dont understand
>> it fully.
>>
>> 3. stackable/modular compression libs- lots of
scanners give back jpeg as
>> their native format, and we usually open it up to a
huge pixmap, just to
>> hand to front-end. this is esp. noticable over
saned. zlib, jpeg, what
>> else?
>>
>> 4. inconsistent option names and arguments between
backends.
>>
>> 5. inconsistent gamma/brightness/contrast
implementations (sanei_gamma
>> i have been playing with here)
>>
>> 6. persistent device naming. none of this
libusbxx
stuff, i want
>> the backend to provide the name, using something
like serial number,
>> rather than using the sanei_usb name.
>>
>> 7. inconsistent conf file layouts- i actually would
like to see something
>> more like samba.conf, with [sections], etc.
>
> 	Some months ago, it was thought of exposing
configuration parameters the same
> way the scanning parameters are exposed. That would
allow frontends or other
> tools to configure backends easily.

but then the frontend would have to do that every time you
made a scan? 
these type of settings usually stay set once determined, and
some of them 
might be bad for the equipment if set wrong, so now you have
to worry 
about user accidentally changing one.

>
>>
>> 8. inconsistent debug levels. not that big of a
deal i guess. i would
>> rather that they were a bitmask instead of a linear
progression.
>>
>> 9. i HATE the frontends changing br-x/y and tl-x/y
into t/b/l/r- i have a
>> front-end that takes cli args like scanimage, and i
have to do the same
>> option manipulations so that users can use their
scanimage commands in my
>> prog. it also means that my back-ends provided help
text for those options
>> is not useful.
>>
>> 10. button support. getting better, but not there
yet.
>>
>> comments?
>>
>> allan
>>
>> --
>> "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
>
> Regards,
> 	Stef
>

allan

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

On Fri, 15 Dec 2006, Gerhard Jaeger wrote:

> On Thursday 14 December 2006 21:18, m. allan noah
wrote:
>> On Thu, 14 Dec 2006, Giuseppe Sacco wrote:
>>
>>> Hi Gerard and all SANE developers,
>>>
>>> Il giorno gio, 14/12/2006 alle 13.40 +0100,
Gerhard Jaeger ha scritto:
>>> [...]
>>>> But I think you are right, we are moving
into a dead-end. We have
>>>> devices that are able to do much more than
we are able to support
>>>> with the SANE 1 standard AND we have a not
yet finished (if finished
>>>> ever) SANE 2 standard.
>>>>
>>>> I'd like to hear/read some more opinions on
that.
>>>> Any?
>>
>> i would vote for re-openning the discussion of
SANE2, and begin a project
>> to port a limited number of backends forward. use a
whole new SONAME, such
>> that sane1 and 2 libs can co-exist for awhile. many
backends will never be
>> ported to sane2, because the scanners have not been
made in 10+ years, and
>> there is no-one to do it.
>>
>> my personal list of things other folks have
mentioned:
>>
>> 1. i hate threading/forking in backends. it makes
debugging a mess, and
>> there are plenty of non-interactive uses for sane
that dont need it (the
>> single most popular front-end, scanimage, for one
 As
per recent
>> discussions on this list, any frontend that cares
about non-blocking, has
>> already implemented a threading solution to deal
with all the backends
>> that block. lets drop the non-blocking functions.
>
> okay - move that responsibility over to the frontends?
Otherwise the
> responsiveness of i.e. XSane will decrease to zero.

i think 'zero' is a bit overstated. only during image
aquisition would 
it appear 'frozen'.

A. there are so many backends that block, most interactive
frontends 
should already thread/fork to deal with this.

B. dealing with children and installing signal handlers in
the backend can 
interfere with the front-end, for those platforms that
fork().

C. backends become harder to debug. given the large number
of backends vs 
frontends, and the unmaintained status of many backends,
anything that 
makes them smaller/easier is good, as it increases the
chances of them 
getting fixed by a novice.

>
>> 2. network protocol overhaul- this keeps coming up,
but i dont understand
>> it fully.
>
> No idea about that, but I think there are others
around.
>
>> 3. stackable/modular compression libs- lots of
scanners give back jpeg as
>> their native format, and we usually open it up to a
huge pixmap, just to
>> hand to front-end. this is esp. noticable over
saned. zlib, jpeg, what
>> else?
>
> ACK.
>
>> 4. inconsistent option names and arguments between
backends.
>> 5. inconsistent gamma/brightness/contrast
implementations (sanei_gamma
>> i have been playing with here)
>> 6. persistent device naming. none of this
libusbxx
stuff, i want
>> the backend to provide the name, using something
like serial number,
>> rather than using the sanei_usb name.
>> 7. inconsistent conf file layouts- i actually would
like to see something
>> more like samba.conf, with [sections], etc.
>> 8. inconsistent debug levels. not that big of a
deal i guess. i would
>> rather that they were a bitmask instead of a linear
progression.
>
> Full ACK.
>
>> 9. i HATE the frontends changing br-x/y and tl-x/y
into t/b/l/r- i have a
>> front-end that takes cli args like scanimage, and i
have to do the same
>> option manipulations so that users can use their
scanimage commands in my
>> prog. it also means that my back-ends provided help
text for those options
>> is not useful.
>>
>> 10. button support. getting better, but not there
yet.
>
> ACK
>
> 11. Overhaul build system
>

suggestions for that?

allan

> - Gerhard
>
>
>

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