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 🙂
Undead
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 :).
Étienne.
Job found
September 18, 2008
Hi,
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.
Regards,
Étienne.
GNOME Scan idled
June 5, 2008
Hi,
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.
Regards,
Étienne.
No GNOME Scan 2.24
May 5, 2008
Hi,
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 🙂
Regards,
Étienne.
Preliminary developments for 0.7
May 3, 2008
Hi,
I’m not good at following GNOME schedule. I do everything one or two month later :). I just started diving back in the development. I started by providing GEGL vala binding, without exactly knowing whether i will actually need it for GNOME Scan 0.8. Anyway, i activated vala in GNOME Scan build system. How long before automake support vala ?
I bumped version to 0.7.0 and will work on GNOME Scan. However, i have tons of things to do aside GNOME Scan : exams, scouting, drive permit, etc. I wish i’ll have the time to develop GNOME Scan before the freezes. Contributions are very welcome. However, GNOME Scan 0.8 needs some rework that can’t be done by a usual contributor. For sure, vala will speed up GNOME Scan development.
A good news, the windfarm_pm121 driver i wrote for iMac G5 iSight has been merged in Linus Torvald own tree 🙂 I’m now one of the thousands contributors to linux kernel ! Thanks Benjamin Herrenschmidt for allowing this to happen.
This and GNOME Scan tells me that developing free software is actually what i want to do. This is why i submitted my CV to o-hand for their job offer for junion kernel developer and junior GUI developer. I know i can’t move on London next year, but working with a senior developer on free software is actually what i want to do for my firsts years of work after the university.
Regards,
Étienne.
GNOME Scan 0.6 in OpenBSD
April 14, 2008
GNOME Scan API at library.gnome.org
March 26, 2008
Hi,
Many thanks to Frederic Peters, GNOME Scan ref doc is now at library.gnome.org : http://library.gnome.org/devel/gnome-scan/0.6/. If you fill adventurous, you could try writing a plugin for you prefered app or write a standalone app on top of GNOME Scan. Beware that API is supposed to change for 0.8, in order to provide bindings (Gobject introspection and vala first, then python and more).
Regards,
Étienne.
SANE misunderstanding
March 17, 2008
Hi,
Sometime, SANE is actually going to make me cry. Today, i posted opened three discusions at sane-devel. I finished the work on hal-scanner, a proof of concept for HAL scanner support. In order to be clearer, i splitted all i had to say in three discussion. Let me review each of them.
HAL and scanners
This is a long standing issue. SANE, in order to be portable, integrates very bad with guest host device handling. HAL handle properly storage, camera and webcam but not scanner. A key point is to either pass an UDI to SANE or compute a SANE device name in order to open the device in SANE. SANE device name is a bit like v4l://0 device name you might have seen for webcam.
Obviously SANE people are completely ignorant of HAL. HAL is used in distros since 2004 or so. As usual, SANE people are very conservative. I wish this discussion will lead to a better solution than the current hack in hal-scanner to compute device name.
HAL scanner addon
Then, i announced my work on HAL scanner addon. I should have added “Announcement” to the title. Anyway, some people took it as an attack to impose some piece of code in the project. I even wonder if they opened the source tarball.
Well known sensors
In SANE, sensors are option and have three fields : the name (an untranslated string, like an identifier), a title (short string translated) and a desc (long translated description of the option). Currently, some backends use “button 0”, “button 1”, etc. as name. This is pretty useless unless asking user to configure manually each sensor … The worst use case is when your grand ma push the cancel scan and just get a popup : “What do you want to do when pressing ‘button 3’?”. In GNOME, i want to make it just work.
This is why i proposed to have common semantic accross backend. I propose to have commone “email”, “print”, “scan”, “cancel”,”adf-opened”, “paper-in” and “auto” buttons. I also suggest to use boolean type for push button rather than integer. Prefixing name with “button-” or “sensor-” might help.
Conclusion
Sadly, SANE people want absolutely the user to configure each action, like KScannerButton does. I’m completely convinced that SANE is actually designed with backend developer point of view only. See this quote:
the button should be called something as close as possible to the
writing on the scanner, not the front-end authors list of words he
understands. there is no ’email’ button on a fujitsu, there is a ‘Send
to’ button.[…]
then, you dont need to interpret the values, you only need to ask the
user- what do you want to do when ‘Send to button’ is pressed?
I completely disagree with the last part. We at GNOME are in war against popup (see Evolution 2.22), against useless question, against confusing UI. Scanner library goal is to provide a device independant access to scanner in order GUI to provide smart behaviour and ergonomic GUI and, again, make things just work.
All in all, sane-devel discussion are always at the border-line of becoming a flamewar. Each part don’t want to understand others point of view. Allan Noah from SANE had a good view of the situation with SANE :
[LSB people] are so used to thinking about their application,
that they forget to do a sales pitch with people outside their group.
i think we SANE devels suffer from the same problem.
Allan Noah is really a nice guy. fujitsu backend is well written. But he is very conservative and strangely didn’t link my request to its current fujistu implementation. fujitsu backend already have semantic button ! And a lot lot of buttons ! A paradise of buttons ! Exactly what i asked for. That’s sad to see one of the best SANE developer forgetting to understand frontend point of view not as in KDE, but as in GNOME.
Anyway, HAL scanner support is becoming more than a proof of concept. There are still tons of area for improvments in GNOME Scan itself, OCR, image processing and more. Just that damn inconsistency in SANE backends make me sad.
Regards,
Étienne.
GNOME Scan 0.6 ready for wider adoption
March 11, 2008
Hi,
Finally, i got GNOME Scan 0.6 ready and sync with GNOME 2.22. This release is a big milestone. Let me expose you all the changes since 0.4.
- Completely redesigned and rewritten
- Modularize all the acquisition pipeline from the scanner to the sink.
- Dynamic pipeline plugins parameter list exposed to the UI
- Based on GEGL for huge sized image handling and much much more
- multi thread anywhere : probing, acquisition and more
- acquisition from images
- automatic per application scan settings saving in GConf
- optionnal automatic color enhancement
- available in 15 languages
- Streamlined GUI for mass acquisition
- extended SANE driver support and workarounds
- Regression: no PDF nor JPEG saving
Please make a big welcome to this milestone, ask your distro to publish it along GNOME 2.22 and report ideas, bugs and more for the future.
- http://ftp.gnome.org/pub/GNOME/sources/gnome-scan/0.6
- Available in my PPA for gutsy and hardy.
As 0.6 says, the road is long before 1.0 which will be hopefully synced with GNOME version number. Amongs other things here are the plans for the future:
- Consolidate code and API. This is important before producing bindings, tutorial, etc. for wider adoption from developers.
- Split dialog code for better reusability
- Review preview UI management
- improve option handling, especially for high level option like PaperSize, etc.
- Improve device handling: status/error reporting, opening in seperate thread, etc.
- Merge scan dialog and acquisition dialog, allow to configure next scan without relaunching dialog
- Use hal scanner API and hotplug smoothness as well as signal monitoring
- Fully migrate to GeglOperation, this avoid us to split the progress bar in 3 stage.
- Support sheet-fed scanners, webcam, etc.
- PDF, jpeg, printing and more for flegita.
I started some weeks ago the work on hal-scanner. It’s going well, i’ll submit it to HAL and take it in account as soon as possible in gnome-scan. Packages will always be in my PPA.
Don’t hesitate to report well commented bug for GNOME Scan . You know i really want to finally fix this big whole in GNOME and desktops in general about scanning. Your use case, your ideas, your hardware specific behaviour/feature interest me a lot. Reporting all that in bugzilla allow me to have a high view of all the neds and design properly for most uses. Thanks
Regards,
Étienne.