Loud ramblings of a Software Artisan

Friday 31 March 2006

STL

STL, Standard Template Library is probably the most frightening component of C++. It is not required to use it for C++ programing, but it actually provides lot of base algorithms and containers.

When AbiWord started around 1998, the state of C++ compilers was not that great. Since AbiWord was supposed to be cross-platform, it was decided of a limited set of C++ features allowed to be used: no template, no exceptions, no multiple inheritence. That made the STL inappropriate, so base classes where written: vectors, hash tables, etc. Actually some containers like hash tables are in triplicate, including one that it barely used.

In 2004, after having lot of issues with our vector class using void* as a container type when storing integer values on 64-bits platform we decided to go with some templated classes. In fact I just templated one of the hash classes, the vector class and the stack class. Only simple template, no template function, in order to avoid possible pain with non conformant compilers, even if at the moment we only build using either gcc, or for Windows, Visual C++.

Now, I'm work on wrapping UT_Vector around a std::vector, and I will do so for some other classes. The idea is to switch to the STL (Standard C++ Library) and avoid the burdain of maintaining our libraries. At the moment everything compiles fine, but with a few glitches at run time. I'll post some benches once I have done some, including memory usage and binary size.

Thursday 16 March 2006

Shall AbiWord drop non-Gtk?

Note: this only represent a personal view and does not represent the view of the AbiWord project.

I asked myself a question: shall we focus on one true Open Source platform, or shall will disperse the effort, trying to compete with the two other OS vendors, and waste lot of resources on that with more flexibility by maintaining AbiWord on Win32 (using Win32 APIs) and on MacOS X (using Cocoa)?

One of the "selling point" of AbiWord was that it was multiplatform, and unlike OpenOffice, it was using the native toolkit of each platform, ie Win32 on Windows, Gtk+ on UNIX and Cocoa on MacOS X. But this advantage is in fact being a real constrain, slowing us down in our developments. Writing a cross-platform UI is no picnic. It actually requires a lot of efforts and compromises, and these compromises are sometime really hard. For example there is still no support for SVG in AbiWord because one of the issues is printing them. To print them you need to provide these vectors to each and every printing backend, which is not an easy task: just rastering as a bitmap is not enough, so you need to have a SVG rendering in the native vector system (GDI on Windows, CoreGraphics on Cocoa, and so on). Another example is object embedding: we still don't do it, at least not in a standard way. Jean Brefort is doing some work with libgoffice to integrate the various GNOME-Office programs (mainly Gnumeric) to AbiWord, but the feature GNOME only. This is quite unfair to the other platforms, but it is still better than nothing. And this provide more credibility towards GNOME-Office, a project that only a fistfull hand of developers believe in. And AbiWord is depending more and more on GNOME technologies. Dom has started work to require libgsf for AbiWord, that create a glib dependency for all platform, depency already there for the OpenDocument filter.

Now lets go with the maintenance burden. So far the Gtk/GNOME version is the most complete and reliable. Why? Because it is the one where most of the developers put the work there, second being Windows. MacOS X is sort of lagging behind (I plead guilty for that), and Win32 still has issues.

It is time to pick a direction. Freedom has a price. We wanted to give users the freedom to use their platform of choice but today we pay the price as it slow us down to provide the best application possible, with the most complete feature set. With the Win32 and Cocoa ports of Gtk+, it might be viable to just use that toolkit on Windows and MacOS, sacrifying a bit of platform integration for a lot of features. A big tradeoff, but after all, users are happy with OpenOffice that do brings its own toolkit to provide features, so why not AbiWord?

The definite advantages I see are:

  • easy SVG support, the dirty work being done with Cairo (actually that can be done now)
  • object embedding with the rest of GNOME-Office. Jean Brefort has done some dirty work for that, but it is Gtk only. Since Gnumeric is Gtk-only it sort of make sense.
  • platform equality

Shall we or shall we not? Proceding so would have us to require what Gtk+ requires. On Mac, it is MacOS X 10.4 (I was targetting 10.3 at that time, but who cares. I don't even run 10.4 anyway), while AbiWord currently targets 10.2. On Windows, I think it is Win98 and NT as a minimum, while AbiWord still works on Win95 (11 year old!).

This question hasn't been really discussed with the other developers.