[sane-devel] API addition request

Hello, On Aug 24 10:16 Kai-Uwe Behrmann wrote (shortened): > Am 24.08.10, 10:06 +0200 schrieb Johannes Meixner: >> On Aug 20 11:50 m. allan noah wrote (shortened): >> >>> Johannes- If we had two trees, and they used the same soname/soversion >>> such that only one could be installed at a time, w

[sane-devel] API addition request

Am 24.08.10, 10:06 +0200 schrieb Johannes Meixner: > Hello, > > On Aug 20 11:50 m. allan noah wrote (shortened): > >> Johannes- If we had two trees, and they used the same soname/soversion >> such that only one could be installed at a time, which one would SUSE >> ship? The old, no changes version,

[sane-devel] API addition request

Hello, On Aug 20 11:50 m. allan noah wrote (shortened): > Johannes- If we had two trees, and they used the same soname/soversion > such that only one could be installed at a time, which one would SUSE > ship? The old, no changes version, or the new, more features, might > break some frontends ve

[sane-devel] API addition request

Johannes Meixner wrote: Hi, > Therefore I dare to suggest to branch the current sane-backends > into two branches: [...] > What do you think? Two branches, one too many. JB. -- Julien BLACHE GPG K

[sane-devel] API addition request

Hello, On Aug 19 20:39 m. allan noah wrote (shortened): > Extending the caps SHOULD work perfectly with any reasonable > front-end. As long as the developer checks for each cap he cares > about, adding a new cap is not a problem. > > However, it is technically possible that a stupid programmer co

[sane-devel] API addition request

Johannes- If we had two trees, and they used the same soname/soversion such that only one could be installed at a time, which one would SUSE ship? The old, no changes version, or the new, more features, might break some frontends version? allan -- "The truth is an offense, but not a sin"

[sane-devel] API addition request

Am 19.08.10, 20:39 -0400 schrieb m. allan noah: > While I am of the opinion that he deserves to feel some pain for that > kind of horrible code, the end user of his code does not deserve > breakage. > > I really, really want to commit your patch (after changing to the US > spelling :) but I cannot,

[sane-devel] API addition request

Hello, Am 19.08.10, 18:22 +0200 schrieb Julien BLACHE: > Kai-Uwe Behrmann wrote: > SANE 1 has always been frozen, and an attempt at thawing it a bit to > extend the API/ABI in a backward-compatible way has failed > spectacularly. Now, I see my subject line was misleading. The SANE_CAP_COLOUR is

[sane-devel] API addition request

Extending the caps SHOULD work perfectly with any reasonable front-end. As long as the developer checks for each cap he cares about, adding a new cap is not a problem. However, it is technically possible that a stupid programmer could do something like an if() test, after masking off all the bits

[sane-devel] API addition request

Kai-Uwe Behrmann wrote: > The patches are for SANE only and have API and ABI wise not much side > effects. Most apps will work as usual. Some apps can make use of the > additional informations from the patch. But there is no requirement to > do so. > > Is SANE already frozen? SANE 1 has always b

[sane-devel] API addition request

Hello, Am 19.08.10, 17:35 +0200 schrieb Julien BLACHE: > Kai-Uwe Behrmann wrote: >> Does this relate to the patches themself or is it outside of my scope? > > It relates first and foremost to the state of SANE, SANE2, etc, etc. The patches are for SANE only and have API and ABI wise not much sid

[sane-devel] API addition request

Kai-Uwe Behrmann wrote: Hi, > Does this relate to the patches themself or is it outside of my scope? It relates first and foremost to the state of SANE, SANE2, etc, etc. Unfortunately we seem to be stuck right now with no solution in sight and as it is we wouldn't have enough manpower to produ

[sane-devel] API addition request

Am 19.08.10, 12:23 +0200 schrieb Julien BLACHE: > Kai-Uwe Behrmann wrote: >> Any chance to get the supplied patches accepted in the current >> sane-backends git? > > In the current state of things, no. Does this relate to the patches themself or is it outside of my scope? kind regards Kai-Uwe Be

[sane-devel] API addition request

Kai-Uwe Behrmann wrote: Hi, > Any chance to get the supplied patches accepted in the current > sane-backends git? In the current state of things, no. JB. -- Julien BLACHE GPG KeyID 0xF5D65169

[sane-devel] API addition request

Am 20.06.09, 16:37 -0400 schrieb m. allan noah: > On Sat, Jun 20, 2009 at 3:21 PM, Kai-Uwe Behrmann wrote: > >> Viannis SANE_CAP_COLOR is, in contrast to the below data structure, a macro >> defined flag for the SANE_Option_Descriptor::cap. >> The suggested flag is API and ABI backward compatible.

[sane-devel] API addition request

On Sun, 21 Jun 2009 20:04:15 -0400 "m. allan noah" wrote: > Well, if we dont use params, our only choice with the current API is more > well-known options. One advantage of moving maintained backends to a new > package would be the possibility of regularizing/requiring such options... right!

[sane-devel] API addition request

On Jun 22, 2009 2:04am, "m. allan noah" wrote: > unless the pages are single sided prints. it would seem that only the > user could know that information, so it is probably a good idea to ask > them instead of the backend... Absolutely. I was explaining why the flatbed/ADF/duplex flags were u

[sane-devel] API addition request

On Sun, Jun 21, 2009 at 11:33 AM, Jeffrey Ratcliffe < jeffrey.ratcliffe at gmail.com> wrote: > 2009/6/20 m. allan noah : > > But, back to Jeffrey's request- is it enough to know ADF or not and > Duplex > > or not in the params struct, or do you need to know that sooner? Also, it > > would be good

[sane-devel] API addition request

2009/6/20 m. allan noah : > But, back to Jeffrey's request- is it enough to know ADF or not and Duplex > or not in the params struct, or do you need to know that sooner? Also, it > would be good to know which side of the duplex scan this is... For me, it is all about predicting the page numbering.

[sane-devel] API addition request

On Sun, 21 Jun 2009 14:31:21 +0200 (CEST) Kai-Uwe Behrmann wrote: > If the system cares for this stuff or there is a relyable path to > communicate a ICC device profile, its all easier - even though still not > simple. Of course we need to define a path for vendors to deliver their > device pr

[sane-devel] API addition request

Am 21.06.09, 12:33 +0200 schrieb Alessandro Zummo: > On Sun, 21 Jun 2009 09:50:33 +0200 (CEST) > Kai-Uwe Behrmann wrote: > >>> even when it is off. If we make it part of a sane 2 standard, then we can >>> require that backends set the bit properly. >> >> Agreed for sane 2 to official support the

[sane-devel] API addition request

On Sun, 21 Jun 2009 09:50:33 +0200 (CEST) Kai-Uwe Behrmann wrote: > > even when it is off. If we make it part of a sane 2 standard, then we can > > require that backends set the bit properly. > > Agreed for sane 2 to official support the SANE_CAP_COLOR flag. Should the default behaviour of a

[sane-devel] API addition request

Am 20.06.09, 16:37 -0400 schrieb m. allan noah: > On Sat, Jun 20, 2009 at 3:21 PM, Kai-Uwe Behrmann wrote: > >> Viannis SANE_CAP_COLOR is, in contrast to the below data structure, a macro >> defined flag for the SANE_Option_Descriptor::cap. >> The suggested flag is API and ABI backward compatible.

[sane-devel] API addition request

Viannis SANE_CAP_COLOR is, in contrast to the below data structure, a macro defined flag for the SANE_Option_Descriptor::cap. The suggested flag is API and ABI backward compatible. So this change will be a very light one. kind regards Kai-Uwe Behrmann -- developing for colour management www.beh

[sane-devel] API addition request

Alessandro Zummo wrote: Hi, > The problem with SANE is that you might loose support for hardware > which is still in use. Most of the unmaintained backends are for hardware that's so old nobody has used it in the past *years* with SANE, in some case even without SANE. So that really doesn't

[sane-devel] API addition request

On Sat, 20 Jun 2009 12:54:44 -0400 "m. allan noah" wrote: > > ?So you force it to either switch or to maintain two trees. > > Julien's idea is precisely not to maintain two trees, but rather to > abandon ancient code. Every other project I have ever been involved > with has some mechanism to r

[sane-devel] API addition request

On Sat, Jun 20, 2009 at 3:21 PM, Kai-Uwe Behrmann wrote: > Viannis SANE_CAP_COLOR is, in contrast to the below data structure, a macro > defined flag for the SANE_Option_Descriptor::cap. > The suggested flag is API and ABI backward compatible. So this change will > be a very light one. > yes- I

[sane-devel] API addition request

On Sat, 20 Jun 2009 09:58:03 -0400 "m. allan noah" wrote: > > If we have decided to break for sane 2, it might be worthwhile > > to do that in such a way to avoid troubles in the future. > > > but this does not avoid troubles, it just pushes them out to the front-end > developer, forcing hi

[sane-devel] API addition request

On Sat, 20 Jun 2009 09:38:24 -0400 "m. allan noah" wrote: > We could do that, but then any front-end that uses sane would have to check > the backend version number and the params version number. I would be more > inclined to convert 'last_frame' to 'flags', then you can probably get by > without

[sane-devel] API addition request

On Sat, 20 Jun 2009 14:18:00 +0200 Alessandro Zummo wrote: > > While we are at it, It would make my life easier if there were > > something to indicate whether the scan is from the flatbed or ADF, and > > if the latter, whether duplex or not. > > agreed. should be easy too. We could grow SA

[sane-devel] API addition request

On Sat, 20 Jun 2009 12:29:55 +0200 Jeffrey Ratcliffe wrote: > While we are at it, It would make my life easier if there were > something to indicate whether the scan is from the flatbed or ADF, and > if the latter, whether duplex or not. agreed. should be easy too. -- Best regards, Alessa

[sane-devel] API addition request

On Sat, Jun 20, 2009 at 10:14 AM, Alessandro Zummo wrote: > On Sat, 20 Jun 2009 09:58:03 -0400 > "m. allan noah" wrote: > >> > ?If we have decided to break for sane 2, it might be worthwhile >> > ?to do that in such a way to avoid troubles in the future. >> >> >> but this does not avoid troubles,

[sane-devel] API addition request

Hello all, Regarding the need for ICC profile support with SANE, I would like to suggest an API addition in the form of a SANE_CAP_COLOUR capability flag. This may not solve the problem as a whole, but it is enough for the gsoc project with locally attached scanner and also would be needed a

[sane-devel] API addition request

While we are at it, It would make my life easier if there were something to indicate whether the scan is from the flatbed or ADF, and if the latter, whether duplex or not. Regards Jeff

[sane-devel] API addition request

On Sat, Jun 20, 2009 at 9:49 AM, Alessandro Zummo wrote: > On Sat, 20 Jun 2009 09:38:24 -0400 > "m. allan noah" wrote: > > > We could do that, but then any front-end that uses sane would have to > check > > the backend version number and the params version number. I would be more > > inclined to

[sane-devel] API addition request

On Sat, Jun 20, 2009 at 8:42 AM, Alessandro Zummo wrote: > On Sat, 20 Jun 2009 14:18:00 +0200 > Alessandro Zummo wrote: > > > > While we are at it, It would make my life easier if there were > > > something to indicate whether the scan is from the flatbed or ADF, and > > > if the latter, whether