Did a 1.2.1 release to get the accumulated polish out into the world. Things are looking good. Only a couple of crash reports, lots of enhancement requests. Sleep has been at a premium with the new baby, so I've taken to doing the massive rename that we'll need to support libgnumeric during the 1.3 cycle. That's a nice simple, mindless exercise. Basicly s/Foo/GnmFoo/ everywhere. It's also a good chance to do some api review. We appear to have a new version of grandma-chema, grandma-lukeh. He's filed a swath of nice crisp bug reports to keep me honest. Having a good collection of bug reporters is tremendously valuable.
The main source of complaints and problems we're seeing in Gnumeric are related to printing. Chema just hasn't been interested in doing much maintenance in there for far too long. Out of desperation we're joining the maintainer team for the project. Hopefully, we can get things back onto an even keel.
Things have been busy since my daughter arrived 2 weeks ago. She's treating us nicely, and has been much easier to take care of (feed change repeat) now that we're not afraid of breaking her. Of course its never quite that easy. The first munchkin is still only two, and while he seems to really like her ('can I pat her head') he also has absolutely no notion of gentleness. So a statement like 'look at the little eyes' is usually done with a small finger jabbing towards the eyes :-)
ssconvert lands in CVS.
People have been asking for cmdline access to gnumeric's importers and exporters for years. I've always resisted writing it because it seemed like such a perfect starter project for someone. After receiving three requests in one day I broke down and knocked off a quick wrapper.
150 lines of code, with attribution and fancy white space for the exporter list.
To be honest it did take a bit of tweaking to force it to work without a DISPLAY, and there are definitely lots of bells and whistles to be added. However, if you need to convert to or from xls it'll get the job done.
xls -> html
xls -> latex
OO -> ... well you get the idea
Now we need to add support for command line flags to configure the importers and exports.
Gnumeric 1.2.0 has been surprisingly stable given the amount of last minute churn. We really violated every tenet of a release freeze except the test suite validations. A couple of moderate crashers have shown up but nothing really major. We're getting some useful feedback on performance now. Things look good, but a few cases for large data sets have forced us to tweak things.
1) row height autosizing was being very stupid. Why bother rendering a cell to calculate its height if it doesn't wrap. By definition all we need there is the font height. Huge space saver when reformating 1 million cells
2) Do not call _() in your value parsing routines. DOH! gettext is expensive with that many calls.
The relative quiet has given me time to get caught up on all the pending patches. Improved svg export for the charts, better heuristics for auto selecting range for autofilter, and more ATK relations for the dialogs.
Probably do a 1.2.1 this weekend to get some of the patches and tweaks out.
Of course that schedule is pretty flexible, depending on the arrival time of goldberg-v2.2 (potential code name 'pretty in pink')
That was painful. Its been almost 20 months since the 1.0.x series came out and we've spent alot of time tuning the engine adding features and puttering along waiting to get the charting engine back on line. I'd have prefered to have done 2 possibly even 3 stable releases in that time frame.
The new engine is now at the point where its architecture seems to have proven itself, and there are enough features implemented that its useful. sample
So what does the future hold ?
I'm dividing goals into 3 broad catagories
1) Improving Gnumeric
Its been a grind to get charting back in Gnumeric but at long last there is a framework in place. Its still a touch rough around the edges, with some tuning necessary in the libart backend, and lots of unfinished bells and whistles. However, it is quite modular, easy to understand, and has a decent interface to Gnumeric.
I'm not thrilled with the bleed through on bars with 0 separation due to antialiasing, and the fringing should also be tuned.
In other news Morten has been banging away at full throttle and has us mostly multi-head aware. He and Andreas have also been scrubbing text import/export to get tie down utf8 issues. The rest of the system is pretty much ready to freeze. Although 1.1.17 was not announced due to late breaking bugs, 1.1.18 is shaping up very nicely.
I should probably do a quick status report given that gnumeric 1.2 is about to miss its worst case deadline by a few months. Development is progressing nicely in all areas accept graphs where things are still unclear. With the hibernation of Guppi we're left without a gnome2 ready engine and will probably end up using a bastardized version of gtkextras-2 with some guppi goodness thrown in.
For everything else gnumeric is kicking butt and taking names. The XLS export is in great shape, conversion to gsf is done, and autofilter support has landed. Heck even pivot tables look possible. The new target for release is the begining of april. Hopefully by then graphs will be solved.
Ok, researched OLE property sets and started work on reading and writing them. It should not be bad, although I was surprised that both libole2 and POI had some rather significant confusion here. However, adding this did not solve the warning from MS Excel so I was forced to merge in patches 1 at a time from 1.1.5 to present to see where the exported file went wrong. It turned out to be the selection exporter. The old version just hard coded A1 the new version tried to be correct, and ended up specifying the selected pane as #0. Excel did not like that. It wants the pane to be #3 if there are no splits.
Once that was found it was time to release 1.1.8 so that the pango code can get some testing.
Phew it may not be as bad as I feared. The OLE exported was mostly correct, but libole2 was using the bats rather than the stated sizes to build files. This ran into trouble when we padded unused bat elements with 0 rather than 0xfffffffe to indicate unused.
MS Excel is still complaining. However, I'm starting to suspect that it is not the OLE. When I simply clone an existing xls file into a new wrapper using libgsf MS Excel is fine with it. That leads me to beleive that the problem is either with the lack of metadata (which is temporarily disabled in gsf) or a new bug in the XL exporter. We'll see. Either way it is not too bad. New releases of gsf and gnumeric to be made shortly to make sure stable gnumeric can read the generated xls from the development version.
On a positive note support for pango in cells just landed in CVS. There will definitely be some performance tuning and some utf8 bugs to work through but a big piece is there.
1.1.7 is also surprisingly stable, we've been kicking the importers and exports around alot and they are in decent shape. Unfortunately it looks like there are still a few gotchas in the gsf OLE export code. libole2 could not read it and XL complains. I'm working to fix it now.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!