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
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, or the
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, which one
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, as
Johannes Meixner jsmeix at suse.de 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 http://www.jblache.org
jb at jblache.org
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
Am 20.06.09, 16:37 -0400 schrieb m. allan noah:
On Sat, Jun 20, 2009 at 3:21 PM, Kai-Uwe Behrmann ku.b at gmx.de 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
Am 19.08.10, 12:23 +0200 schrieb Julien BLACHE:
Kai-Uwe Behrmann ku.b at gmx.de 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 Behrmann ku.b at gmx.de 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 http://www.jblache.org
jb at jblache.org
Kai-Uwe Behrmann ku.b at gmx.de 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
Hello,
Am 19.08.10, 17:35 +0200 schrieb Julien BLACHE:
Kai-Uwe Behrmann ku.b at gmx.de 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
Kai-Uwe Behrmann ku.b at gmx.de 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
Hello,
Am 19.08.10, 18:22 +0200 schrieb Julien BLACHE:
Kai-Uwe Behrmann ku.b at gmx.de 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
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
On Jun 22, 2009 2:04am, m. allan noah kitno455 at gmail.com 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
On Sun, 21 Jun 2009 20:04:15 -0400
m. allan noah kitno455 at gmail.com 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
Am 20.06.09, 16:37 -0400 schrieb m. allan noah:
On Sat, Jun 20, 2009 at 3:21 PM, Kai-Uwe Behrmann ku.b at gmx.de 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
On Sun, 21 Jun 2009 09:50:33 +0200 (CEST)
Kai-Uwe Behrmann ku.b at gmx.de 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
Am 21.06.09, 12:33 +0200 schrieb Alessandro Zummo:
On Sun, 21 Jun 2009 09:50:33 +0200 (CEST)
Kai-Uwe Behrmann ku.b at gmx.de 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
On Sun, 21 Jun 2009 14:31:21 +0200 (CEST)
Kai-Uwe Behrmann ku.b at gmx.de 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
2009/6/20 m. allan noah kitno455 at gmail.com:
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
On Sun, Jun 21, 2009 at 11:33 AM, Jeffrey Ratcliffe
jeffrey.ratcliffe at gmail.com wrote:
2009/6/20 m. allan noah kitno455 at gmail.com:
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
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
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
On Sat, 20 Jun 2009 12:29:55 +0200
Jeffrey Ratcliffe jeffrey.ratcliffe at gmail.com 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.
On Sat, 20 Jun 2009 14:18:00 +0200
Alessandro Zummo azummo-lists at towertech.it 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
On Sat, Jun 20, 2009 at 8:42 AM, Alessandro Zummo azummo-lists at towertech.it
wrote:
On Sat, 20 Jun 2009 14:18:00 +0200
Alessandro Zummo azummo-lists at towertech.it wrote:
While we are at it, It would make my life easier if there were
something to indicate whether the scan is from the
On Sat, Jun 20, 2009 at 9:49 AM, Alessandro Zummo azummo-lists at towertech.it
wrote:
On Sat, 20 Jun 2009 09:38:24 -0400
m. allan noah kitno455 at gmail.com wrote:
We could do that, but then any front-end that uses sane would have to
check
the backend version number and the params
On Sat, 20 Jun 2009 09:58:03 -0400
m. allan noah kitno455 at gmail.com 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
On Sat, Jun 20, 2009 at 10:14 AM, Alessandro
Zummoazummo-lists at towertech.it wrote:
On Sat, 20 Jun 2009 09:58:03 -0400
m. allan noah kitno455 at gmail.com 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.
On Sat, 20 Jun 2009 12:54:44 -0400
m. allan noah kitno455 at gmail.com 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
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
On Sat, Jun 20, 2009 at 3:21 PM, Kai-Uwe Behrmann ku.b at gmx.de 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.
33 matches
Mail list logo
