[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 version? I would provide both in two separated RPMs with different RPM names where both RPMs provide the same RPM capability sane-backends but with mutual RPM conflicts tags to make sure that only one can be installed at the same time. Furthermore I would enhance our YaST scanner module to support switching back and forth between them so that our users can try out which they like more. It would depend on user feedback (in particular during our beta-tests for an upcomming openSUSE version) if we prefer the old one to be installed by default or the new one. We did the same kind of switching for our printing system:
[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, or the new, more features, might break some frontends version? I would provide both in two separated RPMs with different RPM names where both RPMs provide the same RPM capability sane-backends but with mutual RPM conflicts tags to make sure that only one can be installed at the same time. Furthermore I would enhance our YaST scanner module to support switching back and forth between them so that our users can try out which they like more. It would depend on user feedback (in particular during our beta-tests for an upcomming openSUSE version) if we prefer the old one to be installed by default or the new one. We did the same kind of switching for our printing system: From LPRng+lpdfilter to CUPS. As long as a setup tool (like YaST) provides the end-user an easy way to switch back and forth there is no real problem. Initially the old stuff was the default, then we switched to the new stuff as default (this is the actual switch from the end-users point of view), and a longer time later we dropped the old stuff - first we dropped support for the old stuff in YaST but kept its RPM packages and at the very end we dropped also the old stuff packages. Via our openSUSE build service I can provide a new sane-backends at any time via a separated package repository so that interested users can install it on demand whenever they like (but there would be no automated replacement of an installed sane-backends package on a user's system). Can you please post your OBS repository with the patched sane-backend. I would like to use it to build the Oyranos SANE configuration module. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[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, which one would SUSE ship? The old, no changes version, or the new, more features, might break some frontends version? ... Via our openSUSE build service I can provide a new sane-backends at any time via a separated package repository ... ... Can you please post your OBS repository with the patched sane-backend. If the SANE project had two trees, I would provide both trees via our openSUSE build service. I like to provide only what is officially accepted by the SANE project. If you like to build your particular sane-backends version, you could use the openSUSE build service as well - it is available for everybody - but you would need to sign up before you could use it: http://en.opensuse.org/ http://en.opensuse.org/Portal:Development http://en.opensuse.org/Portal:Build_Service https://build.opensuse.org/ Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex
[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, as the possibility of breakage is enough. I understand now the reasoning. Nonetheless I might provide a patched version for specialised graphics distributions, with US spelling ;-) kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] API addition request
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 GPG KeyID 0xF5D65169
[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 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 compatible. So this change will be a very light one. yes- I dont think anyone will object to this. however, no backends will set the bit without a change, so then you are forced to assume it is always on, 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. allan Ping :) Any chance to get the supplied patches accepted in the current sane-backends git? https://alioth.debian.org/tracker/index.php?func=detailaid=312641group_id=30186atid=410366 kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] API addition request
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 -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] API addition request
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 GPG KeyID 0xF5D65169
[sane-devel] API addition request
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 manpower to produce a revamped version of SANE :/ YMM(and will)V JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] API addition request
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 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? If the SANE_CAP_COLOR flag will be a design decission for SANE2 as well thats fine, but no precondition for its usefulness in SANE. With the experiences in SANE there will come experience and ideas about how to best add a similiar or better feature to SANE2. Unfortunately we seem to be stuck right now with no solution in sight and as it is we wouldn't have enough manpower to produce a revamped version of SANE :/ I know of that difficult situation. However, having the patch applied to git would save us work in later patching sane by hand and convincing distributors to do as well. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] API addition request
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 always been frozen, and an attempt at thawing it a bit to extend the API/ABI in a backward-compatible way has failed spectacularly. So unless we want to restart that effort, I don't see how your patch can get merged in SANE 1. Not that I don't want it, note. JB. -- Julien BLACHE http://www.jblache.org jb at jblache.org GPG KeyID 0xF5D65169
[sane-devel] API addition request
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 SANE_CAP_COLOUR is merely a flag. So I would suggest a API/ABI checker can not detect that. All the patch needs in the headers is: +++ include/sane/sane.h #define SANE_CAP_ADVANCED (1 6) +#define SANE_CAP_COLOUR(1 7) The remainder is in the backends. So unless we want to restart that effort, I don't see how your patch can get merged in SANE 1. I shurely would not want that. Not that I don't want it, note. Thanks for considering. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[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 he does NOT care about, or doing a switch/case with all the possible combinations listed, instead of testing the bitmask. 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 the possibility of breakage is enough. We need SANE2 so badly it hurts, but it seems we have less cycles than ever to do it... allan On Thu, Aug 19, 2010 at 3:49 PM, Kai-Uwe Behrmann ku.b at gmx.de wrote: 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 SANE_CAP_COLOUR is merely a flag. So I would suggest a API/ABI checker can not detect that. All the patch needs in the headers is: +++ include/sane/sane.h ?#define SANE_CAP_ADVANCED ? ? ? ? ? ? ?(1 6) +#define SANE_CAP_COLOUR ? ? ? ? ? ? ? ?(1 7) The remainder is in the backends. So unless we want to restart that effort, I don't see how your patch can get merged in SANE 1. I shurely would not want that. Not that I don't want it, note. Thanks for considering. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password ? ? ? ? ? ?to sane-devel-request at lists.alioth.debian.org -- The truth is an offense, but not a sin
[sane-devel] API addition request
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 flatbed/ADF/duplex flags were useful. 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... Indeed. If the option names were standardised, then this would the problem on its own. Regards Jeff -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090622/06c00b2b/attachment-0001.htm
[sane-devel] API addition request
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 options... right! so, what's the path toward 2.0? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[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 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. yes- I dont think anyone will object to this. however, no backends will set thanks the bit without a change, so then you are forced to assume it is always on, Agreed, a patch covering the sane included backends should be created and proposed by us. 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. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] API addition request
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 behaviour of a backend not to alter the color output as much as possible? I recently noticed, while working on the epson2 color correction profiles, that the default option told the scanner to adapt for CRT monitors. I'm planning to introduce profiles shortly and to revert this default to no correction. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[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 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 behaviour of a backend not to alter the color output as much as possible? This is a difficult question for the transistion period. Currently Xsane and scanimage can apply colour profiles on the frontend side. They do not know if a image is prematched or in some more native device space? I could imagine one backend option like: colour-convert - system, not in backend [0] (default) - backend to sRGB, not in system [1] The first value would allow the frontend to take over profile selection, while the later works as last rescue for colour management unaware frontends. This option should remain non mandatory and almost not used or implemented. Colour management in backends is regarding user interaction a complex thing. It will confuse users easily and increase support requirements. If something does not work, it can not even called a bug, it will be called quickly bad design. 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 profile along with a driver and correctly install them. This is work to do. I recently noticed, while working on the epson2 color correction profiles, that the default option told the scanner to adapt for CRT monitors. ... for preview pourpose? I'm planning to introduce profiles shortly and to revert this default to no correction. Yes, fine. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org
[sane-devel] API addition request
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 device profile along with a driver and correctly install them. This is work to do. for example epkowa has some profiles in the form of a .c file and I consistently get better colors with them. I recently noticed, while working on the epson2 color correction profiles, that the default option told the scanner to adapt for CRT monitors. ... for preview pourpose? dunno. it was old code from the original epson driver. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] API addition request
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 the page numbering. For a flatbed, you only want to scan one image, and for any more than that, provide a delay or a prompt giving the user time to change sheets. Scanning double-sided sheets from a non-duplex ADF require the page numbering to be inc/decremented by 2. It would be better for the frontend to know this sooner than the param struct, as that way you can only offer the options that are currently possible. I assume, though, that this would require all options to be reloaded. If this is a problem, getting the information in the param struct would certainly be better that then current situation. Regards Jeff
[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 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 the page numbering. For a flatbed, you only want to scan one image, and for any more than that, provide a delay or a prompt giving the user time to change sheets. Scanning double-sided sheets from a non-duplex ADF require the page numbering to be inc/decremented by 2. 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... It would be better for the frontend to know this sooner than the param struct, as that way you can only offer the options that are currently possible. agreed. I assume, though, that this would require all options to be reloaded. If this is a problem, getting the information in the param struct would certainly be better that then current situation. 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... allan -- The truth is an offense, but not a sin -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090621/6c30b99e/attachment.htm
[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 anyway in the long run. Allan suggested this already on the ICC support for SANE thread. I'm attaching an example patch for the pnm backend, so that $ scanimage --help -d pnm would also print out a hint that an option affects colour output. In respect to updating the backends, this flag is optional, so backends that will use it will have color management support, others won't. So, what do you think? Thank's Yiannis -- next part -- A non-text attachment was scrubbed... Name: sane_color_cap_flag.diff Type: text/x-patch Size: 4044 bytes Desc: not available URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090620/ddbba567/attachment-0001.bin
[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, 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. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] API addition request
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 too.
We could grow SANE_Parameter with a flags field and a version field:
typedef struct
{
SANE_Int version;
SANE_Word flags;
SANE_Frame format;
SANE_Bool last_frame;
SANE_Int bytes_per_line;
SANE_Int pixels_per_line;
SANE_Int lines;
SANE_Int depth;
}
SANE_Parameters;
#define SANE_PARAMF_DUPLEX (1L 0)
#define SANE_PARAMF_ADF (1L 1)
We could also add a media type field, with values
like paper, film negative, film positive, .
Having a version field allows to extend it without
breaking compatibility.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
[sane-devel] API addition request
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 flatbed or ADF, and
if the latter, whether duplex or not.
agreed. should be easy too.
We could grow SANE_Parameter with a flags field and a version field:
typedef struct
{
SANE_Int version;
SANE_Word flags;
SANE_Frame format;
SANE_Bool last_frame;
SANE_Int bytes_per_line;
SANE_Int pixels_per_line;
SANE_Int lines;
SANE_Int depth;
}
SANE_Parameters;
#define SANE_PARAMF_DUPLEX (1L 0)
#define SANE_PARAMF_ADF (1L 1)
We could also add a media type field, with values
like paper, film negative, film positive, .
Having a version field allows to extend it without
breaking compatibility.
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 changing existing backends (other than a word substitution).
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...
allan
--
The truth is an offense, but not a sin
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090620/d2d8551c/attachment.htm
[sane-devel] API addition request
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 version number. I would be more inclined to convert 'last_frame' to 'flags', then you can probably get by without changing existing backends (other than a word substitution). 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 him to have multiple branches in his code to deal with all the variations. I would much prefer to have the major number of the backend be a contract with the front-end author. If that means we have to leave some unmaintained backends behind, so be it. allan -- The truth is an offense, but not a sin -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090620/19480aa0/attachment.htm
[sane-devel] API addition request
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 developer, forcing him to have multiple branches in his code to deal with all the variations. I would much prefer to have the major number of the backend be a contract with the front-end author. If that means we have to leave some unmaintained backends behind, so be it. So you force it to either switch or to maintain two trees. Oh well, I do not agree, but.. so be it. I'd love to have the media type anyway ;) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[sane-devel] API addition request
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. but this does not avoid troubles, it just pushes them out to the front-end developer, forcing him to have multiple branches in his code to deal with all the variations. I would much prefer to have the major number of the backend be a contract with the front-end author. If that means we have to leave some unmaintained backends behind, so be it. ?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 remove old stuff. Sane should be no different. ?Oh well, I do not agree, but.. so be it. ?I'd love to have the media type anyway ;) And you can get it, along with things that other people want, as long as we are realistic about our capabilites, and we keep the front-end author's job as easy as possible. allan -- The truth is an offense, but not a sin
[sane-devel] API addition request
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 mechanism to remove old stuff. Sane should be no different. The problem with SANE is that you might loose support for hardware which is still in use. Most projects do not carry on hw driver and those who do and followed the path you suggested (i.e. ati and nvidia graphics drivers)... well.. let's just say that the users did not appreciate. ?Oh well, I do not agree, but.. so be it. ?I'd love to have the media type anyway ;) And you can get it, along with things that other people want, as long as we are realistic about our capabilites, and we keep the front-end author's job as easy as possible. nic, thanks ;) -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
[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.behrmann.name + www.oyranos.org
Date: Sat, 20 Jun 2009 14:42:07 +0200
From: Alessandro Zummo azummo-lists at towertech.it
We could grow SANE_Parameter with a flags field and a version field:
typedef struct
{
SANE_Int version;
SANE_Word flags;
SANE_Frame format;
SANE_Bool last_frame;
SANE_Int bytes_per_line;
SANE_Int pixels_per_line;
SANE_Int lines;
SANE_Int depth;
}
SANE_Parameters;
[sane-devel] API addition request
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.
yes- I dont think anyone will object to this. however, no backends will set
the bit without a change, so then you are forced to assume it is always on,
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.
allan
kind regards
Kai-Uwe Behrmann
--
developing for colour management www.behrmann.name + www.oyranos.org
Date: Sat, 20 Jun 2009 14:42:07 +0200
From: Alessandro Zummo azummo-lists at towertech.it
We could grow SANE_Parameter with a flags field and a version field:
typedef struct
{
SANE_Int version;
SANE_Word flags;
SANE_Frame format;
SANE_Bool last_frame;
SANE_Int bytes_per_line;
SANE_Int pixels_per_line;
SANE_Int lines;
SANE_Int depth;
}
SANE_Parameters;
--
sane-devel mailing list: sane-devel at lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject unsubscribe your_password
to sane-devel-request at lists.alioth.debian.org
--
The truth is an offense, but not a sin
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20090620/d8bcfa32/attachment.htm
