SANE misunderstanding
March 17, 2008
Hi,
Sometime, SANE is actually going to make me cry. Today, i posted opened three discusions at sane-devel. I finished the work on hal-scanner, a proof of concept for HAL scanner support. In order to be clearer, i splitted all i had to say in three discussion. Let me review each of them.
HAL and scanners
This is a long standing issue. SANE, in order to be portable, integrates very bad with guest host device handling. HAL handle properly storage, camera and webcam but not scanner. A key point is to either pass an UDI to SANE or compute a SANE device name in order to open the device in SANE. SANE device name is a bit like v4l://0 device name you might have seen for webcam.
Obviously SANE people are completely ignorant of HAL. HAL is used in distros since 2004 or so. As usual, SANE people are very conservative. I wish this discussion will lead to a better solution than the current hack in hal-scanner to compute device name.
HAL scanner addon
Then, i announced my work on HAL scanner addon. I should have added “Announcement” to the title. Anyway, some people took it as an attack to impose some piece of code in the project. I even wonder if they opened the source tarball.
Well known sensors
In SANE, sensors are option and have three fields : the name (an untranslated string, like an identifier), a title (short string translated) and a desc (long translated description of the option). Currently, some backends use “button 0”, “button 1”, etc. as name. This is pretty useless unless asking user to configure manually each sensor … The worst use case is when your grand ma push the cancel scan and just get a popup : “What do you want to do when pressing ‘button 3’?”. In GNOME, i want to make it just work.
This is why i proposed to have common semantic accross backend. I propose to have commone “email”, “print”, “scan”, “cancel”,”adf-opened”, “paper-in” and “auto” buttons. I also suggest to use boolean type for push button rather than integer. Prefixing name with “button-” or “sensor-” might help.
Conclusion
Sadly, SANE people want absolutely the user to configure each action, like KScannerButton does. I’m completely convinced that SANE is actually designed with backend developer point of view only. See this quote:
the button should be called something as close as possible to the
writing on the scanner, not the front-end authors list of words he
understands. there is no ’email’ button on a fujitsu, there is a ‘Send
to’ button.[…]
then, you dont need to interpret the values, you only need to ask the
user- what do you want to do when ‘Send to button’ is pressed?
I completely disagree with the last part. We at GNOME are in war against popup (see Evolution 2.22), against useless question, against confusing UI. Scanner library goal is to provide a device independant access to scanner in order GUI to provide smart behaviour and ergonomic GUI and, again, make things just work.
All in all, sane-devel discussion are always at the border-line of becoming a flamewar. Each part don’t want to understand others point of view. Allan Noah from SANE had a good view of the situation with SANE :
[LSB people] are so used to thinking about their application,
that they forget to do a sales pitch with people outside their group.
i think we SANE devels suffer from the same problem.
Allan Noah is really a nice guy. fujitsu backend is well written. But he is very conservative and strangely didn’t link my request to its current fujistu implementation. fujitsu backend already have semantic button ! And a lot lot of buttons ! A paradise of buttons ! Exactly what i asked for. That’s sad to see one of the best SANE developer forgetting to understand frontend point of view not as in KDE, but as in GNOME.
Anyway, HAL scanner support is becoming more than a proof of concept. There are still tons of area for improvments in GNOME Scan itself, OCR, image processing and more. Just that damn inconsistency in SANE backends make me sad.
Regards,
Étienne.
SANE design
January 23, 2008
Hi,
One anonymous comment worries about SANE 1.0.19 support by Gnome Scan. Well, i don’t have to do anything to support this bugfix release, please ask smart question to the right people, for instance your distribution.
However, i’m very concerned about SANE future. SANE is about to plan a 1.2 release including updated well-known options, additionnal frame type and other minor changes to the standard itself, without breaking compatibility. That’s an amazing news to see things moving around in SANE project. However, this mean also that SANE 2 won’t land before a while.
I’m very concerned by SANE due to its by-design mistakes. Nothing to be shame on, but this lead me to join the last comment about the drop of gnome-scan splash in 0.5 serie (Promised, i’ll add a waiting cursor while probing). Something i’m very sad about is that SANE 2 won’t change this. SANE 2 will not be the opportunity to fix design mistakes, but only to break the API in order to complete the design. SANE 2 is planned to be what SANE 1 should have been. SANE is still designed with only the backend point of view in mind, not the frontend. SANE should take both in account.
A good thing about SANE is the fact it’s in user space. No more kernel module. Just like printers, camera and some other devices. This is better for maintainability and stability. So kernel does not load some .ko. Now, it’s up to the frontend to load some .so (listed in /etc/sane.d/dll.conf and /etc/sane.d/dll.d on debian system). This design completely break hotplug : the frontend will never be launched before the driver. Even worse, the detection itself is done in frontend side. Frontend will never be launched after the device is recognized as a scanner. So, first problem is : no hotplug, by design. There have been some contorsion to plug this mistake, but that always failed.
Do you know why probing is so long ? Because each driver is loaded, and each driver walk all the device tree searching for known device. That’s quite crazy ! The more you have USB port, the longer the probe will take. Another problem steming from this design : no sensor/button handling is possible. You will never have a decent support for having the « push scan button on your device, click ok », or « insert paper, click ok » workflow. Your frontend won’t be launched on sensor/button event : the frontend itself must be launched before polling device registers. Actually, SANE standard doesn’t even talk about sensor, button or event. It’es completely up to the driver to design this. In SANE standard, a button is a feature of the scanner you can trigger by software (e.g. calibration).
I have some idea about what we need. Based on the work both in term of design and code, i started thinking of SANE 10 (or whatever). The idea is to use an architecture similar to Hurd servers, FUSE driver or HAL addon : the driver is standalone programm running in it’s own process, launched by HAL upon plug. The driver use a common backend library to expose a service through DBus/Avahi/Socket/whatever. Service will include procedure for scanning, but also signal for events, function for sharing, etc. The backend library will contains all common op for driver plus some helper. On the other side, a frontend library will allow frontends to talks to driver through native function, hiding DBus/Socket/etc.. Hal will just run lm983x hal://org/freedesktop/Hal/devices/usb_device_0_0_0000_00_1d_1 or hplip-sane hal://org/freedesktop/Hal/devices/usb_device_0_0_0000_00_1d_1, depending on some .fdi files shiped by the project.
I wish this word about SANE will clarify how gnome-scan interact with SANE but don’t trigger flames from anyone.
Regards,
Étienne.
Hacking on Linux, Updates and perspectives
December 11, 2007
Hi,
So, the past few days, i worked to get my iMac G5 iSight to work properly. I wrote a linux windfarm platform driver (thanks to Benjamin Herrenschmidt for mentoring), i ported iSight driver and produces iSight firmware tools. I also helped Alex Deuscher to add support for X600 Pro in radeon.
I commited some fixes and added processing infrastructure and preliminary rotation. Gegl is so helpful. flegita-gimp is now useable (requires latest Gegl SVN). I’m uploading babl 0.0.16 and Gegl 0.0.15 to my PPA. I have to fix some bugs and add rotation button in preview area. I’m not that happy with the relation between UI and core; between params and widgets. It’s not smart enough. I my have to restructure a bit that part to get things right for march. I should add print or at least PDF output support and then debug for march. I have a huge collection of photo to scan, this mean i’ll need a rocking software to get things done without headaches. This will help me debugging behaviour and provide a well designed software. Hope so.
Hacking on linux helps me to dream of a SANE 1 successor. Whatever it’s SANE 2 or another project in freedesktop. The goal would be to provide consistent but extensible drivers, sensor and hotplug smoothness. This could be done nicely providing a library for writing driver. Drivers will be standalone apps that must be launched for each device detected. Those driver will feed HAL, publish through DBus/mDNS/UPnP, etc. transparently through the library. Provides also an external library to query drivers (through DBus/mDNS/UPnP). Once udev/whatever launch the driver, it uses uevent to handle sensor. The hotplug is handled by udev/HAL/whatever. I need to investigate this deeper. I’ll begin some work on that after gnome-scan 0.6 since i’ll have to write a driver for my business card reader.
So, i have work for the next year : Gnome OCR, SANE replacement and all that back in Gnome Scan ! Thanks to gnome-scan 0.5 module support, this will be so easy to add another backend 🙂
Regards,
Étienne.
Picasa for Linux
June 28, 2007
Hi,
Most of you read the latest news about picasa for Linux. Apart from beeing just a wine linked software, thanks to Google for providing regular repository for tons of distros. This is amazing to see such compagny taking FOSS in account, trying to understand the way it works instead of trying to use Windows® methods on Libre systems.
Anyway, the key point about picasa is that scan
feature. You may have found it or not. I guess they use an internal SANE/TWAIN bridge. I have to admit the scanner support is really rought and buggy (or quick and dirty if you mind).
Devices option are dumped with one tab per option group. There is no preview area. The overall UI is messy, inconsistent and unfriendly. I’m not critizing this because it’s proprietary, i bet even Google people behind that think the same.
However, that’s quite obvious why they come to such result. After writing too SANE frontend (considering the entire gnome-scan rewrite for 0.6 release), i can say that SANE needs huge work for frontend developers, for various reasons :
- options are very primitive and not directly suitable for UI (see screenshot : for options for selecting scan area). However, these options are still declared with “high level” meta data such as title, description, etc. suitable for building UI. Options are even grouped.
- backends are very very inconsistent. See my various posts at sane-devel list. SANE 1.X lacked tons of recommendations. That’s normal that SANE 1.0 did not provide all the recommandations for today scanners. However, no update has been done since SANE standard 1.0 publication. That’s the lame. Since, all backends implements options with a lot of originality making frontend developer life a hell.
I would add another problem : misintegration in hosting OS. SANe pretend to be very portable and it actually is. However, portability does not mean integration anywhere with only generic code reduce to the least common denominator. This should mean use of each native OS specific models and structures, all of this abstracted using internals models and structures. That’s true for abstraction layer, device probe, network, etc.
I really like SANE. It’s leightweight. It’s extendable. It’s well designed. Yes, it’s well designed ! However, it’s implementation lakes consistency and real portability.
Étienne.
Releasing 0.4 : « Is your app people-ready ? »
December 19, 2006
Hi all !!
Update: emergency 0.4.0.1 release : fix build failure & include latest swedish translation
For Chrismas, i expected a 0.3.2 release, but enhancments and API breakage are so important, i decided to make a major release. i codenamed this release « Is your app people-ready ? » in order to wink at Microsoft advertisments in the past month : « Are you people ready ? ». I really hate this ads which don’t expose product quality, but “feelings” and “concepts”. That’s manipulation. This release of Gnome Scan add nice smart behaviour that make it very suitable for daily use, both for basic and advanced users.
Highlights
- The scan dialog has been entirely review and is now very consistent with Gtk print dialog. The new dialog implements a mecanism to include extras widget inside the dialog instead of building an entire dialog using provided widgets. This add consistency between app using Gnome Scan, and reduce the amount of code in app/plugin.
- Gnome Scan now implement a smart way of selecting area and rotation for you. Select the device, select the source, select the format and the page orientation. Gnome Scan will compute if the document will be rotated in order to fit the scanner, and centered if you use ADF.
- Gnome Scan preview now allow you to resize only “custom size”. So if you choose A4 paper, you will just be able to move the area. Select back Custom size to adjust area again.
- The preview area now shows a “document” icon in top left corner instead of a centered application icon, this is far more useful when you set the rotation, in order to know where is you document, even if you didn’t trigger preview acquisition.
- Gnome Scan now handle X/Y resolution. Gnome Scan try determine wether the device allow dual resolution and allow you to unsync res.
- Gimp plugin now allow you to choose layer name before scan. The acquisition dialog is now 4 times smaller !!
- Updated translations. Many thanks to Philip Sadleder for deutsch translation, Gil Forcada for catalan translation and Daniel Nylander for swedish translation !
Links
Under the hood
- GnomeScanDialog has been highly reviewed. It now herit (again) from GtkDialog, like GtkPrintUnixDialog. GnomeScanDialog now use GtkNotebook in order to separate fields. This allow to have a tab completely dedicated to preview. In contrary to printing, scan preview is interactive : user can choose area and rotation, this is why i choose to use a tab instead of a separate window. The preview tab is shown only if user select “Flatbed” source.
- The GnomeScanDialog implement a “front widget” mecanism that allow developer to add a custom widget in the General tab, below source and format selectors. There is not yet an API for adding/hiding custom tabs.
- Introducing GnomeScanAreaSelector, a smart widget that allow user to choose document format and orientation. When a device is selected, the widget compute a list of available formats that fit the device geometry. The widget compute if the document needs to be rotated to fit the device geometry and setup the context in order to rotate back the document in the right orientation. This behaviour apply both with flatbed or adf source selected. GnomeScanAreaSelector use new Gtk+-2.10 GtkPaperSize API which use PWG standard for sizes and names.
- Gnome Scan now store wether an area is user defined (custom) or not, this allow GnomeScanPreviewArea to hide resize handle if area is not user defined.
- GnomeScanContext now handle dual resolution. However, i based the device dual resolution capability on SANE 2 standard. SANE backends may implement differently that for SANE 1. That’s one of the problem with SANE.
- GnomeScanPreview and GnomeScanAdvancedPreview has been dropped. They were quite duplicated. now GnomeScanDialog provide a unique preview GUI.
- GnomeScannerSelector has been dropped in favor of GnomeScanListStore which allow to feed both GtkTreeView (implemented) or GtkComboBox. GnomeScanDialog now use a GtkTreeView feeded with a GnomeScanListStore.
- GnomeScanOptionWidget has also been dropped. This widget only added automaticcaly a field before a widget. This widget didn’t allow to keep fields aligned. Now let user use either a GtkTable or frame (like GnomeScanDialog).
- Add a –disabled-gnome option in order to build flegita for xfce desktop target. (Patch from Olaf Leidinger).
How to help ?
- Please test the smart behaviour. If your does not center document in ADF, if should review the process.
- If you didn’t find useful stock paper size, please ask for adding it.
- Please translate this major alpha release.
- If your device handle dual resolution, please test wether Gnome Scan detect this capability.
- Spread the word, ask for package in your distribution or package it !
About Gnome Scan and Gnome
I failed to follow Gnome 2.18 schedule. Mostly because i’m new to free software development, i do not yet manage my work as i want. I often let Gnome Scan hibernate during few weeks, and then develop it during on weeks and produce a release. I wish i’ll be able to spend this week just before tarball dues.
Also, Gnome Scan still have deep API changes. I wonder if i will modify the API to be more consistant with GtkPrint API, as far as possible.
Gnome SVN migration is soon to be completed. I wish to switch to a a gnome as possible hosting solution for SVN, FTP, translation, …
Future
For next releases, i intend to implement a few features.
- Select maximal possible area.
- Auto select area.
- Gamma correction.
- Highlight/Shadow point
- The return of GnomeScanOptionSet.
- Device specific options tab in GnomeScanDialog.
- Depth selection.
- Colorspace selection.
- Whatever you asked for …
SANE and HAL
Currently, SANE manage two task : probe and access. That’s a bad thing. SANE must let OS do the probe and ask it for access. SANE should provide a simple glue between various OSes and driver so that OSes can load driver on plug, monitor buttons, and trigger acquisition. I wish that SANE 2 will move toward this design or scanner in HAL will be a dream (or cost a fork which i really do not want). After 1.0 release, i plan to implement one or two driver for SANE (my father owns about 9 scanners at home from all-in-one printers to various pens), especially a nice business card reader. This will allow me to dive deeply into SANE, hoping to make constructive critic for SANE 2 design. Martin Owens is working hard on Scanner in HAL, wish that for this summer, Gnome Scan will use HAL.
Allan, a most active SANE devloper said that linux distro user often do not use HAL. I really think that’s a mistake. All major distro ship HAL, and tons of other ditros do that too. SANE can handle probe, but must allow OS integration. Mac OS X has nothing for scanners. Vista has a very nice scanner handling (espcially probe and detection), but drivers lakes or are unsusable, also Vista scan UI is a joke (not people ready !). Freedesktops has a huge opportunity to make the difference with proprietary OSes ; Droping “probe each launch” and adding hotplug+button support is a must-have feature to fulfill this goal, along with OCR.
Merry Chrismas and see you in 2007 !
Étienne.
0.3.1, the polished alpha release
October 23, 2006
Hi all,
I’m very happy to announce you the availibility of Gnome Scan 0.3.1. This version is what should have been Gnome Scan 0.3. A lot of bugs has been fixed. Translations are uptodate in french, deutsch and catalan. The data receiving process has been review in order to support Grey, RGB and three-pass acquisition (e.g. all red then all blue then all green data). I intend to support multiple depth in the future. Note that the final result will always be a GdkPixbuf with its limitations : 8bit per sample, RGB only, etc. But choosing lower depth or different colorspace allow to fasten acquisition, and more.
This version include a filled NEWS file for maintainers. Sadly, svn log wasn’t able to output all changelog, need to investigate more in order to get a good ChangeLog file.
Releasing 0.3 « Scan for the Mass »
October 16, 2006
Hi all,
I’m releasing 0.3 release of Gnome Scan. This release add a major feature in GnomeScan and Flegita : Mass acquisition. Now GnomeScan implement acquisition as a set of image. This mean that user/application has to manually stop the acquisition process. The acquisition process take advantage of ADF. In flegita, this is shown by the buttons “Stop” or “Next”. If the output format is PDF, flegita write all image in the same file, one page per image. For other image format, the behavior keep being the same.
The acquisition dialog has been a lot review and is now far more HIG compliant, text are more useful. I also fix a lot of bug, including the crazy value of the progress bar. I updated translation and documentation. I weren’t able to contact the deutsch translator, so only the french translation is updated.
Download at usual download page. I update screenshots and documentation at GnomeScan homepage.
Étienne.