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