Updates on development

December 20, 2008


Finally i got acquisition back. There was a huge work on option before getting acquisition. Then i hit some limitation of GEGL. GEGL assume that resource is available before the pipeline is launched. This is the case with files (like in Gimp or scan from file) but not from scanner (nor any network image acquisition protocol). This mean that finally GNOME Scan handle both case : using directly a GeglOp as source or acquire and then process GEGL pipeline. We might also hit another limitation for GEGL for sink : GEGL may ask the sink to process one sub-area of the image. That’s pretty annoying for OCR.

So this mean that instead of fully migrating to GEGL operation, GNOME Scan allow to use a unified GEGL pipeline, but allow as well to implement processing outside a GEGL operation.

Anyway, i write a struct similar to a GEGL operation to handle all the data translation between SANE and GEGL so that the code keeps files light and code readable. Maximum file lenght is 436 lines for generic option handling, and this file is almost finished. Compare with old gsane-scanner.c with its 1236 lines or gsane-meta-params.c with 833 lines or the worst : gnome-scan-dialog.c was 1438 lines !

Even vala generated C files are not that long. That’s a one of the goal of 0.8 : refactor in order to be more maintainable and contributable đŸ™‚

Development took some times and i’m searching a flat for the next month. So i may postpone 0.7.1 for 2009. I may even postpone 0.8 for 2.28 if i can’t get feature parity in time for feature freeze. Philip and I are maintaining 0.6 series. It is a quite stable series with a fairly good support for SANE backend diversity and i don’t want to provide a less stable release. Patches welcome, especially to maintain 0.6, there is a dedicated branch GNOME_SCAN_0_6.



Leave a Reply