December 11, 2009
GNOME Scan is a asleep. Bugs are triaged and sometime fixed, but no development occurs on master.
There is tons of features to implement. Many uses cases and users. This is definitively a nice project. GNOME Scan just needs love.
So anyone wanting to write code, add features, use new GNOME technologies is welcome. I’ll be glad to help anyone !
July 14, 2009
Finally, GNOME Scan 0.6.2 got updated in Ubuntu. They used the old “gnomescan” packaging so if you use my packaging (in my PPA), you should uninstall it before using Ubuntu packaging.
Fedora and Foresight looks updated.
May 8, 2009
Since january, i’m obviously too involved in projects, scouting, work and life in general. I couldn’t allocate time for GNOME scan, only the minimal for git migration. Today i migrated GNOME scan to vala master. I can’t predicate 0.8 release. I’m managing my involvements to reduce the amount of work needed. GNOME scan will be a winner in the long term. I’m attached to GNOME scan, i just need to be less involved.
Anyway, contributions are welcome
January 31, 2009
After 0.7.1, i paused my GNOME Scan development for few weeks. Luckily, i got some feedback about 0.7.1 and 0.6.X releases. Thanks to Philipp, the bugzilla is active. Today i woken up the development by adding a shiny new feature of GNOME Scan that make it actually a library, not a standalone program. This feature is inspired by the TWAIN standard i took some time to read. I call this feature « option preselection ».
This feature allows end application to preselect various properties of option on all the nodes. Currently, only default value is implemented, but the final goal is to constraint logically hardware option. E.g. : only allow to select in RGB, ont Grey ; or add standard Picture format to format selector in your f-spot scanner plugin. Currently only default value is handled. I added back the “Use screen resolution as default resolution” feature in flegita.
In 0.6, application could override a value in GnomeScanSettings thus preselecting default value. This was an unpredicted feature :). But it shows its limits when it comes to constraint values.
Maintaining 0.6 branch
With Philipp, we are doing a good job on maintaining 0.6 series. This series is not that bad. Today i fixed the Gimp plugin to properly handle gray scan. We plan to release 0.6.2 a soon as possible. I would like to fix support of SANE backend using pixel unit for scan area.
There is also some bugs that cause GNOME Scan to crash randomously at startup. I suspect thread managment to cause this behaviour. Very bad bug :). That would be good to have it fixed for GNOME 2.26 in a 0.6.3 release. No plan through.
Developping 0.7 branch
For now, i want to implement a good preview handling in GNOME Scan, taking advantage of the new option infrastructure (both model and UI). After that big point, i’ll add processing back (rotation, correction, etc.) and option persistance in GConf.
December 25, 2008
Finally, there won’t be 0.7.1 for Christmas. Sorry :). Actually, SVN is pretty close to 0.7.1, i just don’t have the time. And would like to improve debugging output before releasing.This will be hard to get 0.8 in time with 2.26, but i’m working on it :). GNOME Scan SVN is very active these weeks.
Current status is quite good. Dialog, option and job has been mostly rewritten. GSane backend has increased image format support, handle mass acquisition and i just commited paper-size support. Overall architecture is better. The software actually allow to do basic scan : put your paper on top right corner, select papersize and trigger scan. That’s pretty minimal : no preview, no custom area, etc.
I’m thinking of a way for application to add prerequisite : default value, constraint (range or enum) and maybe other things. I have some preliminary code. GNOME Scan 0.6 allow default value but wasn’t designed too. GnomeScanOptionManager will have a lot of job compared to it’s predecessor GnomeScanSettings.
Tomorrow, i’ll leave for Roma for a week :). So trunk should be quite silent. However, Philipp has some time to dive into 0.6 branch, fix some bug and maybe release a 0.6.2 :). Thanks Philipp for you help on 0.6
Happy new year!
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.
December 11, 2008
Let me expose some changes that happen on SVN. This is quite technical but shows the progress.
- I committed GEGL vala binding to GEGL SVN. It is used by Gnome Scan SVN.
- Lots of update on the GUI : the selector and the options on the front tab are now packed in a Paned container allowing user to choose the space to allocate to each part of the tab. Useful for people having a lot of scanner listed. Other minor or not updates.
- Seperate modules in their own directory in the source tree and other clean up of the project.
- Reintroduction of GSane, the SANE GNOME Scan backend. It is unusable yet. More on this below.
I remember that before releasing GNOME Scan 0.6, i received help from Ross BURTON aka burtonini. He was very helpful on library, application and building system. However i remember Ross being disgusted by the GSane part. GSane in 0.6 provide far better support than 0.4 SANE-only GnomeScanBackend. However, it was designed and written with a lot of lazyness ;). I’m sometime tired of GObject boiler plate code.
While porting to new lib/, i wanted to make GSane as clear as possible in order to ease contribution and maintainance. So i first took the time to dream, think, sketch and design this sub-project. I took some decisions :
- Seperate modules sources in respective directory
- Don’t be afraid of boiler plate code. Just take to time to write it (just as needed). Thanks to vala for writing all lib/ and src/ boiler plate code. Writing modules/ boiler plate code is note that much code.
- Keep one class per file and avoid unterminating files.
- Don’t gather features in one class or one files. This way is seperated scanner (hardware option probing and lib/ interaction), option handling (translation between SANE and GNOME Scan API, workarounds, feature emulation, high level option implementation, etc.) and acquisition (GEGL operation, frame format translation).
SVN does only probe scanners, open them an retrieve option count. Base class are there, ready for implementing all the option handling (that’s 75% of the job of GSane). I still need to write GEGL operation for scanning. The challenge will be to support unknown length scan (think shedfeed scanner, business card reader and such).
After that, i’ll have to write the preview area and plugins. Then port GIMP plugin and 0.8 will be ready. GSane should be usable for Christmas, however preview may not be ready before 2009. I take to time to do it properly, in order to avoid obscur code and bugs. I’m fed up of rewrite
About 0.6 branch :
Despite the fact that GNOME Scan is 0.X software and thus i don’t support older version, Philip and me are to provide bug fixes for GNOME Scan 0.6. So yes, there will be a 0.6.2.
December 6, 2008
Due to demand, I decided to branch 0.6 and maintain it a bit. Gnome Scan 0.4 is still tryied by some users due to ubuntu but it has blocker bug. So was 0.6 along older version of Gegl. So i updated 0.6 to Gegl 0.0.21 SVN, fixed a tiny bug about cursor and add support for Gimp 2.6 menu layout to Gimp plugin.
Download it at http://ftp.gnome.org/pub/GNOME/sources/gnome-scan/0.6/ .
Today, i got Gnome Scan to actually scan the file. Building the Gegl pipeline is done.next step is to port GSane to new API. There is still a lot of work until feature partity : preview, processing, Gimp plugin, etc. Then documentation etc. Nevertheless, i committed the work to SVN in order to allow tester an contributors to participate. I’ll publish a 0.7.1 version before Christmass at all cost, including no preview or no gimp plugin.
December 1, 2008
The rewrite is going on. I can’t publish it yet because it is incomplete et break a lot of things. Anyway, i want you to know that the project is far from dead. I manage to work on it about few hours a day allowing to make some visible progress.
These days, i almost finished the first two steps : reworking the maindialog. This work consists of merging configuration and acquisition dialog, splitting acquisition dialog into several widgets for handling scanner selector, options (page, box, widgets) and preview. All those rework mean rewriting one way or another. I just choose to rewrite in Vala.
This rework imply a lot of rework in the ground base of the library : options and pipeline représentation. Options are now far more smarter. Options replace old ParamSpec. The difference is in the intelligence in it. Options will handle themselves signaling their changes to other object, they handle their value themselves including saving and storing to GConf (not yet). This will allow saving to GConf high level option like paper size, lists, areas and every boxed type you can find in options.
The option handling has changed a bit in order to completely split engine from GUI. There is now an option manager which stores rules to determine which widget handle one option. It allow to specify a widget to handle an option considering its name or its type. This is far more grained and finally efficient since there is one rule for each instance of option rather than on type stored in each option.
Other area of rework are the pipeline. The job is now constituted of nodes (instead of plugins) with a scanner at begin and a sink at the end. Each node has a status (initializing, unconfigured, ready, processing, etc.) and the job take the status of the least status node (e.g. if scanner is initializing and sink is ready, then gnome-scan is still initializing). Since option are self signaling, nodes knows on the fly the actual value from users, allowing to update their status accordingly (from unconfigured to ready and vice-versa).
On top of that, the new dialog looks exactly the same and behave mostly the same. Changes includes dynamic building of the UI (just to save some CPU cycle before showing dialog), dynamic handling of status (exposing actual status in selector and disabling buttons according to status). This status handling will avoid user to launch unusable scan configuration leading to unpredictable result (i.e. crash).
Options widget are now packed in option box (with bold title), themselves packed in option page (each per tab). All of these widgets are auto-hidden and auto-expanded allowing the dialog to not care about packing option while providing high level widget to build custom dialog.
Also, configuration and acquisition has been merged in the same dialog. This allow to go back and forth. Imagine you just want to change to orientation of the next photo … now you can ! I wonder whether i should expose some options for each scan (like orientation and file name) just below the progress bar. This will allow to name each frame of a scan (be it for flegita filename of f-spot photo description or GIMP layer name). This UI will be greyed during scan. Feedback welcome.
About Vala. This language is pretty cool. Writing 1 line of vala produce about 3,2 lines of C. This helps a lot. In the mean time vala is still a 0.X software (like GEGL, like … GNOME Scan !) and i have to send some patches againts vala binding or vala itself. All in all, vala allows me to write pretty good code and faster. 0.5 rewrite was fast thanks to Anjuta GObject class generator. Vala helps me a lot in rewriting GNOME Scan.
The next step is to build a single instance of the GEGL pipeline allowing dynamic preview. Actually implement acquisition. Then preview and processing will take place. Commit. Then porting gSANE backend and gimp plugin to new API and writing flegita-print (the GNOME photocopier). I have no clue whether i’ll be able to publish a 0.7.1 with feature parity against 0.6.
Oh, i was forgetting the screencast i made, showing some UI changes
November 13, 2008
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 :).