kopia lustrzana https://gitlab.com/sane-project/website
358 wiersze
16 KiB
HTML
358 wiersze
16 KiB
HTML
<!-- received="Mon Aug 30 15:19:17 1999 PDT" -->
|
||
<!-- sent="Tue, 31 Aug 1999 00:19:02 +0200" -->
|
||
<!-- name="Oliver Rauch" -->
|
||
<!-- email="oliver.rauch@Wolfsburg.DE" -->
|
||
<!-- subject="Re: Starting a discussion about SANE and TWAIN..." -->
|
||
<!-- id="" -->
|
||
<!-- inreplyto="Starting a discussion about SANE and TWAIN..." -->
|
||
<title>sane-devel: Re: Starting a discussion about SANE and TWAIN...</title>
|
||
<h1>Re: Starting a discussion about SANE and TWAIN...</h1>
|
||
<b>Oliver Rauch</b> (<a href="mailto:oliver.rauch@Wolfsburg.DE"><i>oliver.rauch@Wolfsburg.DE</i></a>)<br>
|
||
<i>Tue, 31 Aug 1999 00:19:02 +0200</i>
|
||
<p>
|
||
<ul>
|
||
<li> <b>Messages sorted by:</b> <a href="date.html#355">[ date ]</a><a href="index.html#355">[ thread ]</a><a href="subject.html#355">[ subject ]</a><a href="author.html#355">[ author ]</a>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0356.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
|
||
<li> <b>Previous message:</b> <a href="0354.html">Cooper: "Re: Machine lock-ups while scanning. HP scanjet 5P/BusLogic Flashpoint"</a>
|
||
<li> <b>Maybe in reply to:</b> <a href="0084.html">252353N@knotes.kodak.com: "Starting a discussion about SANE and TWAIN..."</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|
||
<!-- body="start" -->
|
||
Hello Mark,<br>
|
||
<p>
|
||
after all I found a bit time to answer at least on of your mails:<br>
|
||
<p>
|
||
<p>
|
||
<i>> The initial proposal is for a single generic TWAIN</i><br>
|
||
<i>> Source that (must) incorporate it's own GUI. Because</i><br>
|
||
<i>> of this the SANE drivers do not have to provide any</i><br>
|
||
<i>> GUIs of their own. In designing such a GUI I would</i><br>
|
||
<i>> create a property sheet with tabs dedicated to areas</i><br>
|
||
<i>> of functionality: Image Processing, Compression,</i><br>
|
||
<i>> Cropping, etc... and let the Source assemble the</i><br>
|
||
<i>> generic GUI based on the feature set it discovers in</i><br>
|
||
<i>> the SANE driver. It's not a perfect solution, and</i><br>
|
||
<i>> comes nowhere near the real intent of a TWAIN GUI,</i><br>
|
||
<i>> which is to represent all the features of a specific</i><br>
|
||
<i>> device. But it should be relatively easy to implement</i><br>
|
||
<i>> and should provide enough functionality to make it</i><br>
|
||
<i>> worthwhile...</i><br>
|
||
<p>
|
||
There is no problem with this.<br>
|
||
A generic sane GUI allows to acces all options the<br>
|
||
sane-backend makes available.<br>
|
||
<p>
|
||
<p>
|
||
<i>></i><br>
|
||
<i>> Re-reading this section, I see that you may also (or</i><br>
|
||
<i>> even only) be talking about the selection of a SANE</i><br>
|
||
<i>> device. This is something I would like to delegate</i><br>
|
||
<i>> to the TWAIN Source Manager. SANE has the ability to</i><br>
|
||
<i>> enumerate it's available devices. The TWAIN Source</i><br>
|
||
<i>> Mananger must provide a GUI option for selecting</i><br>
|
||
<i>> Sources from a list. It would be relatively easy to</i><br>
|
||
<i>> modify the Source Manager to query a SANE Source for</i><br>
|
||
<i>> all the devices that it knows about, and display them</i><br>
|
||
<i>> to the user. Once a selection is made, the SANE Source</i><br>
|
||
<i>> would behave entirely in the manner of the selected</i><br>
|
||
<i>> device...</i><br>
|
||
<p>
|
||
The sane GUI has an own source selection dialog.<br>
|
||
<p>
|
||
For UNIX:<br>
|
||
We will only have sane drivers on unix, so we can<br>
|
||
use the source selection dialog of the sane GUI.<br>
|
||
This would have the advantage that the<br>
|
||
TAWIN-Source-Manager does not need<br>
|
||
an access to the window system. The application<br>
|
||
can link against the Source Manager and is free<br>
|
||
to use the graphical toolkit it likes (MOTIF, GTK, ...)<br>
|
||
The Source Manager would get a lib that implements<br>
|
||
the TWAIN interface to the application and we only<br>
|
||
have to define the communication between the<br>
|
||
Source Manager and the SANE-GUI/driver.<br>
|
||
<p>
|
||
This way we get independent from any graphical toolkit<br>
|
||
and may be we can get independant from any window<br>
|
||
system.<br>
|
||
<p>
|
||
<i>></i><br>
|
||
<i>> Third party code exists which can run WIN32 apps on</i><br>
|
||
<i>> UNIX environments running X-Windows. This is critical</i><br>
|
||
<i>> to an initial assessment of TWAIN on UNIX, since it is</i><br>
|
||
<i>> unlikely that TWAIN will be used by anyone unless it is</i><br>
|
||
<i>> proven that WIN32 developers can move to UNIX with a</i><br>
|
||
<i>> minimum of effort...</i><br>
|
||
<p>
|
||
I do not know the lib with wich you can compile/run WIN32<br>
|
||
apps on X/unix, but I know enough about such things,<br>
|
||
they are<br>
|
||
- big<br>
|
||
- buggy<br>
|
||
- and slow<br>
|
||
<p>
|
||
If someone compiles a professional WIN32 software like adobe photoshop<br>
|
||
this way on a unix machine we get a slow, big, buggy and not professional<br>
|
||
application.<br>
|
||
<p>
|
||
I understand your idea to say: ok, we invest one or two days of work and<br>
|
||
our application will work on n differen unix machines.<br>
|
||
I think we should try to make this possible, but in the foreground<br>
|
||
we have to create a twain standard that is compatible with<br>
|
||
the TWAIN unix standards of the future that have a good implementation<br>
|
||
for unix systems.<br>
|
||
<p>
|
||
If we define a TWAIN standard for unix that is a hack of the WIN32 standard,<br>
|
||
we will never get a TWAIN standard on unix that serious unix programmers<br>
|
||
will use.<br>
|
||
<p>
|
||
So we have to define a standard that works well with unix and that<br>
|
||
is as close to the WIN32 standard as possible.<br>
|
||
<p>
|
||
I think we can hide a lot of the functions in the Source Manager.<br>
|
||
<p>
|
||
<i>></i><br>
|
||
<i>> The problem is that any change requires a change</i><br>
|
||
<i>> to the TWAIN Specification, which then requires</i><br>
|
||
<i>> code changes to Sources and Applications. One</i><br>
|
||
<i>> lesson learned has been "don't break existing</i><br>
|
||
<i>> code". TWAIN is 100% compatable all the way back</i><br>
|
||
<i>> to the first release in 1992.</i><br>
|
||
<p>
|
||
Some minor changes will have to be done for TWAIN on unix.<br>
|
||
Our job will be to keep the changes as small as possible<br>
|
||
but to make a TWAIN standard as good as possible<br>
|
||
for the unix system.<br>
|
||
<p>
|
||
Most of the bad things we put in the standard now<br>
|
||
will stay for ever in it. There will be no chance to<br>
|
||
make a jump and say, ok - now do everything about TWAIN<br>
|
||
from the beginng, So it has to be "good" in the first shot.<br>
|
||
<p>
|
||
<p>
|
||
<i>></i><br>
|
||
<i>> Sooooooo...to my way of thinking, the first</i><br>
|
||
<i>> solution that needs to be provided is one that is</i><br>
|
||
<i>> compatable with existing code. Which, sadly,</i><br>
|
||
<i>> means the event loop.</i><br>
|
||
<p>
|
||
I think this does not need to be a big problem.<br>
|
||
We do not need the most events, so an<br>
|
||
(almost) empty function is good for this<br>
|
||
and we can define that it can be called<br>
|
||
but there is no need to call it if we don`t<br>
|
||
need it.<br>
|
||
<p>
|
||
<i>></i><br>
|
||
<i>> This doesn't mean that we can't add new and better</i><br>
|
||
<i>> methods. Indeed, if we can leverage such ideas</i><br>
|
||
<i>> back to WIN32, then we've accomplished a very good</i><br>
|
||
<i>> thing.</i><br>
|
||
<p>
|
||
That sounds good, but as you say the code is<br>
|
||
compatible from version 1.0 til now so I have no<br>
|
||
great hope that we can do any relevant changes.<br>
|
||
<p>
|
||
<p>
|
||
<i>> However, the existing spec must be dealt</i><br>
|
||
<i>> with or no one will seriously make the attempt to</i><br>
|
||
<i>> cross platforms.</i><br>
|
||
<p>
|
||
Of course. Otherwise - if we start to define a totally new<br>
|
||
standard we could call sane=TWAIN for unix.<br>
|
||
<p>
|
||
<i>> Well, the reason for using X (as opposed to Motif) is</i><br>
|
||
<i>> that the sending of an event should be quite straight</i><br>
|
||
<i>> forward. None of the events sent from the Source to</i><br>
|
||
<i>> the app require any data. As for the events coming</i><br>
|
||
<i>> into the Source, I am recommending that the Source's</i><br>
|
||
<i>> GUI be built with X-windows...it's not the most elegant</i><br>
|
||
<i>> solution, but as stated, it's better than trying to</i><br>
|
||
<i>> deal with all the toolkits.</i><br>
|
||
<p>
|
||
I do not have any problems to say lets say X<br>
|
||
is a "must be" for this, but if we can do all<br>
|
||
that with pipes without any greater problems,<br>
|
||
we should do this with pipes so we do not have<br>
|
||
to force any window system and we can work<br>
|
||
with text based user interfaces or any other<br>
|
||
window system.<br>
|
||
<p>
|
||
<i>></i><br>
|
||
<i>> Simplicity it the catch-phrase for the first cut :)</i><br>
|
||
<i>> As for the IPC API...there is no reason the TWAIN</i><br>
|
||
<i>> Source shouldn't make direct calls to SANE. Again,</i><br>
|
||
<i>> I'm looking for something that takes a minimum of</i><br>
|
||
<i>> effort. If the SANE interface in the TWAIN Source</i><br>
|
||
<i>> is properly isolated behind a SANE class, we can</i><br>
|
||
<i>> replace it later with a more sophisticated IPC</i><br>
|
||
<i>> interface...</i><br>
|
||
<p>
|
||
I think it is not so simple.<br>
|
||
We can do all we want for our own tests,<br>
|
||
but if we define a standard this could have<br>
|
||
influence to the communicatin between<br>
|
||
the source manager and the source, so<br>
|
||
we have to think about this very good!<br>
|
||
<p>
|
||
<i>></i><br>
|
||
<i>></i><br>
|
||
<i>> The GUI is a real nasty problem in a lot of ways,</i><br>
|
||
<i>> mostly because TWAIN users rely on it for access</i><br>
|
||
<i>> to custom features, which, of course, will never</i><br>
|
||
<i>> appear on any generic GUI. We've vastly increased</i><br>
|
||
<i>> the programmatic access in TWAIN to about 150</i><br>
|
||
<i>> negotiable capabilities, which allows applications</i><br>
|
||
<i>> the 'option' of doing their own GUIs, but still</i><br>
|
||
<i>> leaves us with the custom feature problem. Which</i><br>
|
||
<i>> isn't likely to go away, since it's an important</i><br>
|
||
<i>> part of product differentiation for device vendors...</i><br>
|
||
<i>></i><br>
|
||
<i>> By going with a SANE Source, we run the risk of</i><br>
|
||
<i>> ticking off application writers, because the GUI</i><br>
|
||
<i>> they bring up will 'not' carry all the features</i><br>
|
||
<i>> of the device they are using. I feel the risk is</i><br>
|
||
<i>> necessary because (1) it's unavoidable and (2)</i><br>
|
||
<i>> anyone who's gotten that far will probably be more</i><br>
|
||
<i>> than happy to complain to the device vendor for</i><br>
|
||
<i>> them to make a TWAIN driver with a proprietary</i><br>
|
||
<i>> GUI, and this is a good thing, since most driver</i><br>
|
||
<i>> writers will not take action unless someone lights</i><br>
|
||
<i>> a fire under them...</i><br>
|
||
<i>></i><br>
|
||
<i>> One way SANE could address this would be to provide</i><br>
|
||
<i>> a mechanism in the GUI frontend that would allow a</i><br>
|
||
<i>> driver to add custom dialogs or windows. This is</i><br>
|
||
<i>> common practise in Windows, where drivers add custom</i><br>
|
||
<i>> tabs to printer property sheets. If such a mechanism</i><br>
|
||
<i>> was in place, then we might be able to create TWAIN</i><br>
|
||
<i>> Sources with no intrinsic GUIs, which invoke a GUI</i><br>
|
||
<i>> through SANE when it is requested of them...</i><br>
|
||
<i>></i><br>
|
||
<i>></i><br>
|
||
<p>
|
||
<i>></i><br>
|
||
<i>></i><br>
|
||
<i>> Given my thoughts above, and understanding that we are</i><br>
|
||
<i>> talking about a generic GUI going through SANE, and not</i><br>
|
||
<i>> one that is specific to the device (as is really needed)</i><br>
|
||
<i>> I agree with this...</i><br>
|
||
<p>
|
||
Sane is defined a way that each frontend can handle all options a<br>
|
||
backend(driver)<br>
|
||
makes available. So I think there is normally no need for a device specific<br>
|
||
GUI. But if it is needed, there is no problem if TWAIN is able to get access to<br>
|
||
several TWAIN-to-SANE-drivers.<br>
|
||
<p>
|
||
In the moment we have two frontends, a very simple one that only<br>
|
||
gives the user acces to all options the backend enables and a<br>
|
||
frontend that has some improved functions like gamma correction<br>
|
||
visible without a new preview, histogram function ...<br>
|
||
<p>
|
||
<p>
|
||
<i>></i><br>
|
||
<i>> Now, as a driver writer, I'm going to be my own questions.</i><br>
|
||
<i>> What is SANE.</i><br>
|
||
<p>
|
||
<i>> Can I just port my TWAIN driver to UNIX.</i><br>
|
||
<p>
|
||
That will be hard.<br>
|
||
<p>
|
||
<i>></i><br>
|
||
<i>> Will the SANE driver I write for UNIX run on WIN32.</i><br>
|
||
<p>
|
||
That will work if we added the ASPI level to the common functions<br>
|
||
in sanei_scsi.c<br>
|
||
<p>
|
||
<i>> The</i><br>
|
||
<i>> answer to that last one really needs to be yes, if at all</i><br>
|
||
<i>> possible, because most driver writers are desperately</i><br>
|
||
<i>> tight on resources, and will not attempt to cross platforms</i><br>
|
||
<i>> because the effort is too much. However, if they have a</i><br>
|
||
<i>> TWAIN driver running on SANE, they get the best of both</i><br>
|
||
<i>> worlds. Access to new applications through SANE, access to</i><br>
|
||
<i>> their existing base through TWAIN, and they only have to</i><br>
|
||
<i>> write their device communication layer once...</i><br>
|
||
<p>
|
||
That will be no great problem.<br>
|
||
But they will not write a TWAIN driver any more,<br>
|
||
they will have to write a SANE driver.<br>
|
||
<p>
|
||
<i>></i><br>
|
||
<i>></i><br>
|
||
<i>> Yes, the ability of SANE to abstract away the different</i><br>
|
||
<i>> UNIX HAL layers is essential. While I expect most users</i><br>
|
||
<i>> will be targeting Linux, there are some classes of users</i><br>
|
||
<i>> who would be very interested in AIX or Solaris, so having</i><br>
|
||
<i>> a complete UNIX solution is critical from the start.</i><br>
|
||
<i>></i><br>
|
||
<p>
|
||
Did you take a look at the SUPPORTED PLATFORMS on<br>
|
||
the sane homepage ? There is much more than support for linux.<br>
|
||
<p>
|
||
<p>
|
||
<i>> As stated above...given the use of custom features</i><br>
|
||
<i>> the only GUI that will ever expose all of the</i><br>
|
||
<i>> attributes of a given device is the one created by</i><br>
|
||
<i>> that device's manufacturer. This is important to</i><br>
|
||
<i>> understand, and it's driven 100% by the application</i><br>
|
||
<i>> writers, who have always preferred the option of</i><br>
|
||
<i>> using the Source's GUI to creating one of their own...</i><br>
|
||
<p>
|
||
<i>></i><br>
|
||
<i>></i><br>
|
||
<i>> Represents the device to the maximum of the SANE</i><br>
|
||
<i>> namespace...or is there a mechanism in SANE to</i><br>
|
||
<i>> describe custom features? (gosh, this would be</i><br>
|
||
<i>> a wonderful thing)...</i><br>
|
||
<p>
|
||
The sane backend defines a list of options<br>
|
||
using special types like buttons, sliders, menues and so on.<br>
|
||
<p>
|
||
There are some "well known" options like resolution<br>
|
||
and scanarea (some more will come) the frontend should<br>
|
||
take special care of.<br>
|
||
<p>
|
||
For everything else the backend says "make a button<br>
|
||
with the text "XYZ" and tell me if it was enabled or disabled."<br>
|
||
<p>
|
||
So a generic frontend is able to give the user acces to all<br>
|
||
options the backend defined.<br>
|
||
<p>
|
||
<p>
|
||
Puh, that was a lot.<br>
|
||
<p>
|
||
If possible, let`s try to keep the mails a bit smaller,<br>
|
||
than our communication will be a bit faster because<br>
|
||
I will better find the time to answer 5 small mails<br>
|
||
than one of this size! ;-)<br>
|
||
<p>
|
||
Bye<br>
|
||
Oliver<br>
|
||
<p>
|
||
<pre>
|
||
--
|
||
EMAIL: <a href="mailto:Oliver.Rauch@Wolfsburg.DE">Oliver.Rauch@Wolfsburg.DE</a>
|
||
WWW: <a href="http://www.wolfsburg.de/~rauch">http://www.wolfsburg.de/~rauch</a>
|
||
<p>
|
||
<p>
|
||
<p>
|
||
<p>
|
||
<pre>
|
||
--
|
||
Source code, list archive, and docs: <a href="http://www.mostang.com/sane/">http://www.mostang.com/sane/</a>
|
||
To unsubscribe: echo unsubscribe sane-devel | mail <a href="mailto:majordomo@mostang.com">majordomo@mostang.com</a>
|
||
</pre>
|
||
<!-- body="end" -->
|
||
<p>
|
||
<ul>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0356.html">Oliver Rauch: "Re: SANE V2 - again..."</a>
|
||
<li> <b>Previous message:</b> <a href="0354.html">Cooper: "Re: Machine lock-ups while scanning. HP scanjet 5P/BusLogic Flashpoint"</a>
|
||
<li> <b>Maybe in reply to:</b> <a href="0084.html">252353N@knotes.kodak.com: "Starting a discussion about SANE and TWAIN..."</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|