What is wrong with AbiWord?

Posted 21 Jul 2000 at 07:53 UTC by goran Share This

The title is provoking but not intended as a pun towards the AbiSource Community. Many of them are very good programmers some even brilliant craftsmen. What I want to discuss is if cross-platform development is a good objective.

I download the CVS version of AbiWord about a week ago to check out the progress and the code itself. I found good thing and not so good thing. First the good things:

  • The code is well structured an fairly easy to follow when you understand the object hierarchy and directory structure.
  • The program is fairly useful as simple word processor. The only things I miss that I use often in MS_Word is tables and automatic TOCs.

What is bad IMHO (and this is pure opinion) is:

  • It is C++. My first job as a fulltime system programmer was partly based on C++ so I have worked a lot with C++ programming both on system level and with GUI development. C++ combines the worst features of LL and HL programming languages. Argh. C++ also has a weak fit to other object systems like Gtk+, CORBA or OLE.
  • It is (and this is the main point) cross platform code. Lets call it XPcode for short.

Looking at AbiWord, Mozilla and the coming attraction, Star Office, XPcode leads to:

  • Slower development There is more work to read up on several platforms and carefully write portable code. There only are so many hour so it got to mean less feature development.
  • Code bloat An elegant framework to build different platform is the way to go, but that means lots and lots of code before you even got any usable functionality.
  • Platform fit, NOT Xpcode does not give as good fit to each platform a native application. Platforms differs both technically and from user interfaces. Either you got a less then optimal fit with a lowest common nominator approach and you have to crush out lots and lots and even more code.

I am not saying the AbiWord team is doing things wrong really. It is a question of priorities and objectives. They are building a very good product which will be available on multiple platforms. BUT, my impression is that many people (including me) think that what GNOME needs is a word processor which integrate as close as possible (comparable to and integrating with Gnumeric/Dia/etc). The goals is not mutially exclusive, but they put an different emphasis on the work process and the outcome.

The subject for a discussion should be: Is there a need for a new Gnome specific WP?

I have done some work (as experiments and gnome learning experience) using the AbiWord code base. This is what I find should be done in new project:

  • Reduce code bloat by eliminating XPcode. It is possible to flatten the class hierarchy from 3-4 levels to 1 or 2 all over to code.
  • Reduce code bloat by eliminating coded function already available on unix/Gnome. For example:
    • Most import/export filter could be external and developed and maintain separately.
    • Use gnome-xml instead of expat. I already has abiword-format reading (and writing) working with gnome-xml in AbiWord.
    • Use glade to make faster UI development.
  • "Bonoboify" for modularization and integration with Gnome.
  • "un-C++-ify" to make more developers comfortable working with the code.

A forking of resource is not always a bad thing. If the goals are different enough it is a good thing as it could attract new developers to each project. As long as all projects use compatible licences code can be borrowed freely and exchange of idea can continue.

To Summaries:
I have a modified code base and a game plan which could be a start of a "Gnome Word". BUT I will not start a new project without a your input on wheater or not to have a go and do:s and don't:s.
So, comments, please.

XPCode, posted 21 Jul 2000 at 08:28 UTC by mettw » (Observer)

I haven't seen the AbiWord source, but cross platform code can be done efficiently. GTK does it through the GDK wrapper and gmp does XPCode in a similar way by putting all of the asm in a set of standard functions that the more usefull functions are built from.

I'm not sure how it would work with C++ (I'm new to it) but personally I would go for (very) low level C functions to be called from within the C++ objects.

PS: I agree totally with you about C++ - I just wrote a diary entry about the same problems with it.

yes, no and no, posted 21 Jul 2000 at 10:36 UTC by cannam » (Master)

You're certainly right that cross-platform code has some big disadvantages, especially as the most obvious cross-platform projects (e.g. AbiWord, Mozilla, Qt) share very little code. For AbiWord and Mozilla I think there are obvious advantages to a cross-platform effort though, and in the case of Mozilla it's questionable whether the Unix port would have progressed this far at all if it wasn't using a cross-platform toolkit.

There are more similarities between Unix, Win32 and Mac platforms than there were a few years ago too, which somewhat mitigates the "platform fit" problem. Of course, none of the applications I run day-to-day on Unix fit together in any but the most superficial way anyway.

Shame you had to cloud your argument with the C++ bit though. I'm sick of people offering to waste their time rewriting someone else's project just because they don't much like the language it's written in. Don't you think the AbiWord guys had their reasons for choosing C++ in the first place? Would expanding the potential developer base to a few more people who aren't currently AbiWord developers, at the expense of those who are, really be such a good thing?

There are plenty of languages I'm not too keen on, but I've never felt much need to take a project written in any of them and rework it in something I liked better just so I could make some changes afterwards. I work on a Java project daily, and every day I find something else to curse about Java, but I'd be mad to suggest taking this considerable body of code and rewrite it in C++ just because I'm that bit more used to it. In the end it's less effort and more reward to learn to live with the language that's already being used.

(Okay, so the C++ aspect was probably intended to be only a small part of your proposal. But you did list it as the very first of your problems with AbiWord.)

Don't do it, unconstructive, posted 21 Jul 2000 at 11:34 UTC by caolan » (Master)

A quick check of the mail archive for abi for July 2000 doesn't show any mail from you to them as to opening up discussion with the people who know the code best. Perhaps you could submit the gnome-xml patch to them first. Have you discussed the issue with them before you wander off with yet another word processor. Ive seen many of them come and go over the years.

Bonifying would certainly be very nice and Im sure it can be handled within the existing framework, Id really think you'd be on a loser with the deC++ifying approach. I have my own set of problems with C++ and a stack of them with C too, but its a Hobsen's choice between them. I just don't see language choice or even general architectural reasons as a valid reason to fork.

No, basically don't bother with the language fiddling, submit the gnome-xml and bonofication patches. Let the abiword people consider them and fit the ideas into their framework. There is a whole set of general xpcode issues which needs to be worked out for the general case, as there is a large amount of duplication of effort between all the biggies. But the solution is not to tear the heart out of abiword and make it work under unix only. Cross platform is good.

In fact what I'd do is add table and TOC support to abi while you think it over :-)


XPCode, posted 21 Jul 2000 at 13:26 UTC by Guillaume » (Master)

> PS: I agree totally with you about C++ - I just wrote a diary entry about the same problems with it.

I've read your diary entry and frankly I couldn't help wondering if you ever had opened a C++ book :-).

You say you have a hard time passing a string object to a method (that really baffled me :-), and that Haskell achieves the same thing than C++ templates, which means you're missing a lot about templates.

It seems that very often people blaming C++ are people who just haven't learned to use it properly. Yes it has a lot of issues, and it certainly isn't a perfect language, but most of the time the problem is with the programmers.

Reinventing the wheel, posted 21 Jul 2000 at 13:34 UTC by matt » (Journeyer)

The big problem with XP (not Extreme Programming) ;-) is that every project that does it has needs that aren't met by some other XP effort, and they make the decision to create their own XP platform to build their software on top of.

XP would be a lot more valuable if there was some sort of common XP platform that everyone could contribute to. I'm sure licensing issues are a big thing. Let's face facts -- Mozilla could have never built their software on top of a GPL'd XP platform, though perhaps LGPL might have worked.

Unfortunately, what we end up with is a whole bunch of different resource-hogging XP layers, and due to the fact that only one organization is usually using each of these layers, they'll be brought up to the point where they support that organization and nobody else.

Cross platform and native look is possible., posted 21 Jul 2000 at 13:45 UTC by ber » (Master)

Cross platform development can be done nicely. I agree with mettw here. There are no real technical difficulties. Some solid engineering is needed. It was done before (e.g. Openstep which ran on Solaris, its own OS and Windows.) And this is were I see the problem:

Most free software developer do not care enough about a good cross platform framework. There are so many toolkits. But not all of them are application frameworks, some are just GUI kits. We need more efforts towards a concise application framework. Note that gnome and kde are both not going to do it. They are creating their own bubble which is not cross platform to start with. For good or bad, efforts go into these two approaches. If you need an application, you should check different frameworks first instead running with the crowd.

My best bet right now is wxWindows(2) controlled by Python: wxPython. It utilises the native GUI toolkits and APIs on the different platforms which is more important for usability as lot of features.

(Another so so article on the subject: The Importance of the GUI in Cross Platform Development)

Try working within the Abi community before forking, posted 21 Jul 2000 at 14:08 UTC by Uraeus » (Master)

I am just a user of GNOME and Abiword, but I think I will be daring enough to voice my opinion anyway. While I think you have a lot of good ideas, like moving from expat to gnome-xml (at least for the gtk/gnome version), I hope you try working with the current Abi developers before deciding that forking is the best solution.

If I were you I would start with either mailing the abi-devel list or by mailing Joaquín Cuenca Abela directly (Joaquín is the person who has implemented most of the current GNOME support) and try discussing you ideas with them/him.

I think the price for Abi being cross-plattform is actually more than covered through the extra developers it brings in. The loss of progress a C++ to C move would cause in the short term, would probably outweight heavily any long term benefits, I would think that getting bonobo support for Abi, would be time better spent, since it would allow you to develop at least some part of future functionality in C as bonobo components. For example functionality mirroring the 'MS WordArt' thingie I would guess would be nice to implement as a bonobo component.

Re: XPCode, posted 21 Jul 2000 at 14:15 UTC by cannam » (Master)

> You say you have a hard time passing a string object to a method (that really baffled me :-)

I imagine he means it's a simple operation that seems to generate an awful lot of code. Which is probably true. Of course it's simpler in C (want to pass a string by value? copy it yourself).

> that Haskell achieves the same thing than C++ templates

Seems like a fair comment to me. C++ templates and Haskell or ML's Hindley-Milner typing (nostalgic link to my old FP lecturer there) both allow you to make nice generic implementations of things that can then be applied to a set of specific conforming types. The mechanisms are different (IMHO the Haskell version is conceptually and syntactically rather neater) but they permit some similar things in practice.

But even if C++'s templates are a kludge it's still nice to have them at all.

Maybe you can only have one degree of freedom in your toolkit. Most of the cross-platform toolkits (Qt, OpenStep, whatever AbiWord uses) appear to be bound to a particular language; more language-independent toolkits are generally more platform-specific. Same for other sorts of framework: COM is language-independent but very platform-specific, JavaBeans cross-platform but language-dependent.

No, that's nonsense. It's all special cases. A feast of red herrings.

C++ a weak fit to CORBA or OLE?, posted 21 Jul 2000 at 15:13 UTC by Svartalf » (Journeyer)

Uh, while I won't question your skills or your experience, I would ask how long ago did you use C++ with CORBA or OLE and what framework were you using .

The ORB dictates how tightly C++ is associated with CORBA- I know of at least one ORB, designed with C++ in mind and was the first ORB with deterministic behavior, TAO. I'm pretty sure OmniORB2's the same way, since it's supposedly developed with the same C++ thinking in mind. In my case, my previous employer has this nifty distributed real-time financial control system- it uses TAO as the middleware between the Linux based embedded transaction collection systems and the server (Take your pick of OSes for that end- NT, AIX, Solaris, Linux, *BSD, etc.). Without C++ or TAO, this system could have been designed, but it wouldn't have been developed in the 3 months that it went from nothing to initial unit test, and it wouldn't be as easy to figure out how to extend it. Since it's initial release, it's went through 2 major extentions of it's functionality (Going from a parking system to a taxi tracking/billing system...) in 8 month's time- all without breaking the original functionality. Not to say that what we did couldn't have been done in C- I just wouldn't want to try it in the conditions we had to work in.

In the case of COM/DCOM, if you're using the brain-dead primitives layer, then yes, I'd agree with you, C++ is an ill fit. However, MS actually did something right with the most recent versions of VC++ and the other compiler vendors have followed suit. They have COM pointers that act just like C++ classes and they happen to have this nifty template library that makes doing COM/DCOM objects a snap in C++ (It's orders of magnitude easier than trying to roll all of that crap in C and it's about as small as the hand-rolled C code. I wouldn't be developing any COM/DCOM code without ATL and C++; I've been down the C route with it- it's just too painful and clumsy to do on a day-in-day out basis with C.)

I really wouldn't be doing OO development (and that's what we're talking about here...) without an OO language- it's nowhere near as easy to do and you just can't make up for some of the features of C++ or Objective C with C tricks and macros. As for GTK+, I honestly think that it's nice and allows for coding in other languages, but it's somewhat clumsy OO coding-wise because of it's C choice. This is not putting it down- it's an observation of a developer that uses the toolkit. I prefer to use GTK-- to do my GTK+ coding, since it's a fairly thin wrapper around GTK+ that pretty tightly binds to C++. Yes, it's not as optimal (size and perhaps speed wise) as using something like Qt, which is designed around C++, but I think it's more flexible- more akin to the way C++ is intended to be used.

Cross-Platform Compatibility is the Point, posted 21 Jul 2000 at 15:28 UTC by samth » (Journeyer)

I find it remarkable that people write long essays on why cross platform apps are a bad idea.

  • Cross platform is the point with AbiWord. AbiWord is currently the most portable word processor in existance, bar none. The only operating system that it won't run on with any noticeable installed base is the Macintosh, where a port is currently in progress. What this means is that you can seamlessly and perfectly transfer you document from your AIX backend server to your QNX embedded system (provided it has a GUI) to your boss's Windows PC. This is the most important reason for AbiWord. It wasn't originally writtent to be part of the GNOME office (although we are happy to be there). It was written to be as XP as possible.

  • C++ makes cross-platform development much easier. It allows us to express the ideas behind our application hierarchy almost exactly, to encapsulate the platform specific work in the subclasses where it belongs, and to provide an easy-to-use framework for all the platforms. We have deliberatly avoided using advanced features of C++, although this is sometimes controversial, in order to preserve speed and most importantly, portability.

  • Code Bloat: What part of AbiWord is bloated? First, how many other word processors are under 5 MB (including help, with screenshots, and dictionaries, and localization)? Second, how does having XP code add bloat?

  • Slower development: First, writing code that is portable usually means writing code that is higher quality. Second, when working in XP code, it isn't that hard not to use platform specific calls. C++ allows the XP code to make XP calls, which then translate into platform-specific calls further down in the hierarchy. Third, the additional development work that gets done because we have Linux, FreeBSD, Win32 BeOS, QNX, etc developers more than makes up for this mythical slowness.

  • Cross Platform Toolkits (brought up by several people): AbiWord does not use one particular toolkit. Each platform has code for it's native tookit (or GTK+ in the case of Unix). Ports to other toolkits are welcome.

  • Native Look: Because we don't try to use the same toolkit everywhere (in contrast to Mozilla) we have a native look on every platform, from GNOME to QNX.

If you want to add more GNOME support, we are all happy to help you. If you want to send us the gnome-xml patch, we will be glad to look at it. But there's no need to fork AbiWord.

The problem with most app frameworks is..., posted 21 Jul 2000 at 15:29 UTC by Svartalf » (Journeyer)

...that there's enough differences in the way things are done internally on the different supported systems that it's difficult to get a good one- and when you do, it ends up trying to do everything and ends up bloating up your app severely and slowing it down. Prime example- printing.

How does the Mac handle printing?
How does Windows?
How does most Unices?

Each and every one different, isn't it?

For your app framework, do you use each native methodology? If you do that, do you support a limited subset of the native methodology or do you support the whole thing? If you support a limited set, you experience a disconnect from the native environment . If you support everything, you experience a disconnect for the users that cross from one platform to another- and you have the complexity either in the app framework or in your app for dealing with all the differences. Both situations are a problem. And that's just printing- there's tons of other situations just like this one. No, app frameworks, while they can help things for some applications are not the magic bullet that you make it out to be- they can make as many issues for you as they solve.

I agree!, posted 21 Jul 2000 at 15:51 UTC by aaronl » (Master)

I am an AbiWord developer, and while I like C++ more than C, I agree with many of your points.

* Each application should not implement its own XP application framework

* If all the trouble has been taken to write such a framework, it should at least make stuff completely cross-platform. Right now in AbiWord, each dialog needs to be implemented in the native widget set for each platform, and there are several platforms. This is the reason that ports like the BeOS one are falling behind. It takes a lot more effort to implement each dialog 5 times.

In conclusion, I think there is way too much non-XP code in AbiWord, and I hope that this gets worked on. Part of the problem is the "luddites"' phobia of multiple inheritance and other helpful features.

This is why I work on the XP code. I think it's counter-productive to implement each dialog 5 times, but at least I'm not the one doing it.

Attempting a general-purpose XP environment, posted 21 Jul 2000 at 19:10 UTC by gord » (Master)

I'm in the midst of developing a runtime environment that's been designed from scratch to be tiny, platform-independent, language-independent, and useful.

If you're interested in learning more, please go to the Figure home page, and take a peek.

I've got some working code, lots of ideas, but very little documentation. The current agenda is to get the documentation and package system working so that it's easier to exchange ideas about the software.

Re: I agree!, posted 21 Jul 2000 at 20:12 UTC by ithamar » (Apprentice)


I'm a developer trying to help out on AbiWord for BeOS, and would like to respond to the post of aaronl, who said the dialogs in AbiWord were one of the major points of the lagging BeOS port.

I'm afraid I'll have to disagree on that. The implementation for the dialogs is *very* straightforward, but the problems in the BeOS specific parts are much more complex. If I cannot even see a selection, or a cursor for that matter, I think the dialogs are pretty unuseful anyway.

Don't want to offend anyone, but if you take a look at the source, a lot of BeOS specific code is outdated or downright incomplete, and dialogs are just a tiny portion of that.

The Tough Part: Applying MWC, posted 21 Jul 2000 at 23:21 UTC by cbbrowne » (Master)

There are applications which are fairly easy to make cross-platform, and there are applications that aren't.

Something like GnuCash should be relatively easy to make work on multiple "graphics platforms." It only has a GTK-based GUI, at present, and the attempts at a Qt one have been aborted due to the creation of the "register" being a fairly daunting task, but that is representative of nobody really taking the porting task seriously as opposed to there being any fundamental tight coupling to GTK. There is already code that does "transaction stuff," loading data into the system, and querying it, which is straightforward because the basic abstractions have nothing to do with GTK, but rather with the "accounting transaction engine."

In contrast, the big point to something like the GIMP is to "draw stuff." All sorts of system functionality has to couple reasonably tightly with the GUI, which means that changing to use a different GUI system is quite difficult.

Web browsers have provided a model that has been pretty ambiguous; with the varying functionality of IE and NN, and the varying breakages of standards, people have simultaneously been encouraged to be a bit platform-agnostic as well as to couple themselves tightly with whichever vendor provides a bit of sponsorship...

As for AbiWord, it would be nice if the functionality were highly decoupled from the GUI, so that it would be easy to stay agnostic about which GUI was in use. On the other hand, word processing is a pretty visual process, thus encouraging a lot of the development to stay close to the GUI library.

And I think that dichotomy is exactly the point at which the dilemmas come in. There are good reasons to want to decouple views and controllers from the system model, as that makes porting easier. But that decoupling is distracting from the desired result for "highly visual" applications, which is to see the results.

Cross-Platform development necessary to Linux's desktop success, posted 23 Jul 2000 at 15:11 UTC by alanr » (Master)

I worked for Lucent Technologies for 21 years, and quite a few years of that were in IT support for Bell Labs. One of the big reasons that no big company has gone to a Linux desktop isn't that there aren't applications enough (there are), a big factor that no one can switch the entire platform at once.

If one postulates a cross-platform GPLed Office suite which runs on MS-windows and on Linux, and preferably on other UNIces as well, and can successfully import and export MS-word documents, then one can *talk* about converting a large company to Linux without getting laughed at.

If I had such an office suite, then I would pitch it this way:

Look, company X: You're spending $x hundred million each year on Microsoft applications and support. How would you like to cut that in half and not be forced to upgrade continually?

Well, here's the plan: Convert to the AbiWord suite (or whatever) on your existing OSes and hardware, and install all your new machines with Linux and the ABW suite. As machines are retired over the next 2-5 years, you will cut your costs by more than 50% as you buy support from your choice of support companies X, Y, or Z.

You've eliminated your single sourcing of development, of support, cut your budget in half, and converted to the latest in stable, reliable, cost-effective technology, while greatly reducing the cost to the company of dealing with viruses.

Now, isn't that great shareholder value your IT department is providing?

The ticket is to think in terms of what's important to the company's CIO. And that is almost always money in one form or another, and covering their hind-ends. There are several variants on this theme, but they all come down to saving a bunch of money, and making the switch in a way that doesn't scare them to death. Although Word Perfect has the cross-platform part down right, they *don't* have the benefits that make it worth the risk and cost of switching. Which is to say that they are still single-sourced, and the customer is still at the mercy of the vendor. A cross-platform GPLed office suite DOES have sufficient benefit to look like it's worth the switch.

The moral of the story is that we MUST have a cross-platform office suite, whether anyone wants to develop it or not, and regardless of whether it costs more to develop or takes a little longer. It's like saying I don't like to breathe air. It doesn't matter what you like. You need to do it anyway.

Summary, posted 24 Jul 2000 at 17:18 UTC by goran » (Journeyer)

The discussion was partly excellent. The provocating title did it :-)

I will not comment anything but a few thing, since a compelete summary would be longer then the article itself:

  • I should not have bashing C++ since it was not my main point.
  • I did not discuss it on the abiword mailing list since it really was not about AbiWord. You could run sed 's/AbiWord/Mozilla/g' on the article.
  • "Is not"-answer does not convince me. Wellgrounded arguments might
  • A gnome-xml patch is submitted to AbiWord. Hope I can contribute more in the future.
I am still not convinced that platform application development is the best thing for gnome. Perhaps porting Gtk/Gnome to other platforms would be better options, but I will not do it so I have no vote. :-)

Check out these link if interested:
GTK+ for WIn32
GTK+ for BeOS

cross platform user interface, posted 26 Jul 2000 at 23:44 UTC by pcburns » (Journeyer)

If you are doing a cross platform application and it needs a graphical user interface, then you can't go wrong with fltk. Its fast and flexible. It has a simple but extremely powerful gui builder called fluid. The license is LGPL. The latests developments look even more promising. I don't think I'll ever go back to using gtk or qt. It is however, written in c++.

New Advogato Features

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!

Share this page