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.
June 28, 2007 at 10:14 pm
What do you mean with “news about picasa for linux”??? picasa for linux has been out for ages and it is still the same old version you can download from their page (picasa.google.com/linux/)
June 28, 2007 at 10:22 pm
Hi Kim,
The news was the repository for tons of distros and the availability of google-desktop-linux. Sorry for that details, but the freshness of picasa for linux is not the subject of the thread, that’s more about SANE through its use in picasa.
Regards,
Étienne?
June 29, 2007 at 5:51 am
SANE well-designed? Make it handle my scanner with four colours (RGB, infrared) and we’ll talk about well-designed. Or a proper networking protocol. Or maybe scanner buttons?
June 29, 2007 at 12:27 pm
Hi Johannes,
SANE option handling is quite well designed. However, i fully agree, that it needs an update to handle such case. But it was hard to predict the future.
SANE really needs to be used in the desktop in order to evolve. I wish gnome-scan will help SANE people to be aware of the huge value of scanner support.
July 6, 2007 at 12:32 pm
Étienne, sorry, I didn’t read the comments. If you want to continue discussing then we should probably take to email: johannes -at- sipsolutions -dot- net.
A while ago I analysed sane a bit more in-depth and realised that the whole distinction between local and network backends is flawed, it is bad for security (for example with scsi scanners you need full scsi access for every user) and also for other reasons.
Hence, imho the only way to get out of the sane dilemma is to come up with a new sane standard that uses technology such as d-bus or other IPC even locally (images could be passed via shm in the local case, but this should be transparent to the application writer), and a scanner daemon that is invoked on-demand (again something d-bus perfectly handles).
The sane developers have previously said that things such as scanner buttons aren’t manageable with IPC, but I strongly disagree, d-bus provides signals etc.