First 0.7 alpha : 0.7.1

January 15, 2009


After one month of heavy development, i release GNOME Scan 0.7.1. This release is an alpha “preview” of the 0.8 series. It has several regression, however it already show improvments in behaviour, features and support.

You can download it at

See detailed annoucement at including known regressions.

This version is not parralel installable with 0.6. However, you should be able to run it from source : run ./configure && make && src/flegita .

last weeks, i didn’t work as heavily as in december. Some bugs gets fixed in 0.6. 0.8 won’t land along 2.26 because i won’t be able to follow feature freeze and such. This is another good reason to maintain 0.6 branch. Philipp Sadleder is THE maintainer of the 0.6 branch. I fix bug he ask me to fix. He does a pretty good work and help me a lot triaging bug, fixing bug, etc. 0.6 is a quite good version with enhanced support and performance. Even if 0.8 does better in all of these fields, 0.6 is a major release that should have its glory ūüôā

0.8 will be for 2.28. There is good chance to get it with 2.28. There is preview area, processing, flegita-gimp, flegita-print, prerequisite, saving to GConf and other things to implement before 0.8 gets ready. That’s fairly big piece of the project but a huge part has been done. 0.7 has only 1000 C lines less than 0.6.1.

All in all, releasing 0.8 six month later allows other project like vala to evolve and mature. This should make 0.8 a very good base. 0.7.2 will include preview area and prerequisite. I plan to follow 2.27 schedule for beta, string freeze, etc.




November 13, 2008

I’m very proud to announce the inclusion of Philipp Sadleder in GNOME Scan development team. His first commit replaced vapi with gir binding. Welcome Philipp !

Thanks to Philipp, GNOME Scan development wakes up. I’m learning to do few commits after work, trying not to spend all the night debugging ! I fixed a bug in GEGL causing black image and ported GNOME Scan SVN to GEGL SVN.

The schedule is to do most of the hard work before for Christmas and debug, polish, document starting from january to get GNOME Scan 0.8 along GNOME 2.26.

The Roadmap for 0.8 is to review option handline (both design and GUI), add back PDF output, revamp dialog, etc. All new code is supposed to be in vala. I don’t know yet if we can call internal C/Gobject from vala, if not, wi’ll have to rewrite all lib/ in vala. Not that painful since there is a lot of class to split in several class, etc. Vala has also a great advantage : it allows to drop glib-mkenum and friends :).


Job found

September 18, 2008


This year, i’m no longer student. I sucessfuly pass exams and i’m now working as web developer at Nerim. I actually want to take to get GNOME Scan usable this year. Lukily, my employer is quite permissive about how I spend hours at Nerim.I plan to free each wednesday morning to have time for free software, possibily at home. Currently, i work on scout website (yet another project i have to release one time).

Vala has done nice steps forward, but i need .gir support to handle properly subnamespace (Gnome.Scan and not GnomeScan). But that’s a matter only when mixing pure C/GObject and vala code. I wonder if that make sense to rewrite all in Vala. Pretty useless. It even can be a pain to maintain GEGL vapi. I’ll check that as soon as i wake up GNOME Scan.

May GNOME Scan resurect this year.  Patches welcome.



GNOME Scan idled

June 5, 2008


I’m pretty busy with scouting and other stuff. Also vala seems not yet able to handle subnamespace and that break mixing C/GObject and vala (can’t call C/GObject code from Vala). This is pain.

All these issues leads me to idle GNOME Scan for this summer. I’m quite disappointed because i don’t have time but i’m actually willing to get GNOME Scan included. I’m leaving the university and thus i’m searching a job. Next year, i don’t want to move out of Paris, but i actually want to work on GNOME and especially GNOME Scan. I may do a call for a job later.



No GNOME Scan 2.24

May 5, 2008


Next version of GNOME Scan will be 0.8, not 2.24. This show that GNOME Scan won’t be part of GNOME 2.24. A lot of you wonder why, and that’s a good question.

GNOME Scan still immature. 0.8 will see a lot of API breaks. GNOME Scan also depends on GEGL, a far from stable project which is actively developed by √ėyvind Kolas and a lot of other people. SANE support is still incomplete. Some images data are misprocessed, sheetfed and cardreader are not supposed to work properly nor webcam.

Including GNOME Scan in GNOME plateform and flegita in GNOME desktop is not as simple as distributing it by default in your favorite distribution. This mean that we add GEGL as an external dependency, which i guess √ėyvind would not like seems it imply supporting obsolete version. It also mean that GNOME Scan API must be stable enough accross version which i actually can’t assure yet.

However, not being included in GNOME doesn’t forbid your favorite distro to include it, neither your software to have a plugin using it.

All in one sentences : “Don’t include alpha project in GNOME desktop”.

Now, please tell me if i’m wrong ūüôā



SANE design

January 23, 2008


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.



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 ūüôā



That’s bad news, but i’m busy on other projects. I wrote cifrado, a french scouting software. Then i developped the website of my scouting group : Finally, i’m developping Linux PowerMac 12,1 windfarm driver. I own an iMac G5 rev C for two years and Linux still does not run smoothly on it. I should have finished this driver for chrismas.

Gnome Scan is not that far from 0.6. It needs some refactorization of area plugin in order to watch other options, then a better handling of orientation and then processing with rotation. Contribution are very welcome. I’m glad to leave PHP and redevelop in C for Linux, this will help dive into Gnome Scan development. I wish i could have written Gnome Scan using Vala. I promised i will use Vala for libgnocr.


Delaying Gnome Scan 0.6

September 25, 2007

Hi everyone,

With the availability of 2.20, i took the time to consider Gnome Scan inclusion into Gnome. My main concern about that is that Gegl is unstable, both API and behaviour. I decided not to propose Gnome Scan for inclusion. I rather decided to follow Gnome timeline. This mean that 0.6 won’t land for Christmas, but rather for February/March 2008. Thus, i will implement a bit more feature than planned like options saving/restoring.

There is some good news in gnome-scan development for the past few days. I solved some bugs and reworked the processing mecanism. Now Gnome Scan build a unique Gegl pipeline an launch it. To achieve this goal, i commited a new Gegl operation : “convert-format” and fixed some other bugs in “save-buffer”. The next step is to design “processor” plugin to hook between scanner and sink.

I’m a very proud Gegl user and (tiny) contributor. This is the magic of libre software. Related project are not frozen, you can always contribute in order to these project more suitable for other projects :).

Expect some more news about Gnome Scan in the following days ūüôā

What next for Gnome Scan ?

August 22, 2007

Hi everybody,

The end of th Google SoC 2007 does not mean the end of development. I wish every GNOME students will continue to contribute and develop. Of course, i will continue Gnome Scan. Here is some stuff for Gnome Scan futur.

  • mid September : 0.5.2 including resurected Gimp plugin, printing and bugfixes.
  • end October : 0.5.3 including processing and improved preview area.
  • Christmas : libgnocr development should begin in order to get advanced OCR API and UI for Gnome. This will allow to update AbiScan plugin.

This is a rought roadmap, but it shows what i have in mind for Gnome Scan and OCR in Gnome.

I also have a bunch of random feature to implement :

  • scan from PDF (using poppler-glib ?)
  • scan to mail
  • capplet (calibration, color correction, etc.)
  • evolution plugin (scan to vCard)
  • gthumb/f-spot plugin (scan to albums)
  • deskew for everyone
  • bindings in python, C++ (for abiscan), vala, C# (for f-spot), ‚Ķ
  • hotplug with HAL (needs huge discussion and work with SANE people).
  • network sharing (again)
  • ‚Ķ

Stay tuned ūüôā