GNOME Scan

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.