Updates on local work, step 1 : the main dialog
December 1, 2008
Hi,
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 🙂
Finishing the rewrite ; new issues ; toward processing
June 28, 2007
Hi all,
I’m not blogging a lot since i produce weekly report on gnome-soc-list. Also, the motivation is not that high. I continue the new preview area system. It is quite nice. It use GtkStyle colors and is extensible. That’s not easy to rewrite such software. In some hand you got excitation and motivation due to new features and huge improvement, but in the other end, its a bit of duplication, waste of time, etc.
After preview area, the big job is processing. I prepared a bit that part of the software, but wasn’t able to know exactly what i wanted. I guess i will provide a basic processor for rotation and color correction, however i don’t know how to get it really modular. Should i use multiple processors ? Also, i wonder how to take hardware color correction in account as well as calibration.
Anway, i would like to write OCR as soon as possible. Writing a dumb plugin for gedit or abiword would be funny. I tested OCRopus. Well, tesseract SVN did not build so ocropus can’t be built. tesseract development seems not active. I know some people are working on it, but not in the official SVN. Finally, i found a patch in their bugtracker which solved the problem. Tesseract and OCRopus definitly needs some feedbacks. This is where gnome-scan comes at point.
Even if OCRopus is far from yet ready for distribution, i investigate into it. Gnome Scan en Gegl are is similar state. I wish this will help and motivate their developers. Some projects really needs some love. Let’s give it what they need.
OCRopus should require an additional dialog with preview of the result. I bet the new preview area will be suitable for this thanks to it’s modular design. The new preview area will also fit exotic needs like multiple area without bloating the library.
Étienne.