Author: Marco Fioretti
In OpenOffice.org (OOo), the most popular free software office suite, macros are usually written in the StarBasic language. Today, however, StarBasic macros have a couple of problems. The first is the one I touched on in Fixing the problems with OpenOffice.org extensions: at least on GNU/Linux systems, macros should not be distributed inside self-executing OOo files because they don’t integrate with a distribution’s native package management.
The second issue is more general and, at least in the long term, more of a hassle for free software users. One of the features highlighted in the OOo 2.0 release is the use of the OpenDocument format as the default file format. The OpenDocument format is being adopted by StarOffice and KOffice as well, is recommended by the European Commission, and currently on its way to becoming an ISO standard.
OpenDocument’s adoption as a native format by OOo, KOffice, and other office suites is a wonderful thing — but it also creates a problem as far as macros are concerned. At some point OOo and KOffice users will exchange OpenDocument files that contain OOo macros that won’t work in KOffice programs. Because the programs share a common file format, users will expect that the macros will work in either program. After all, the macros are part of the file, and users are told that one of the benefits to OOo and KOffice is that they utilize a common format. But there is no macro language specification in the OpenDocument specification, and everyone I’ve talked to agrees that there shouldn’t be.
I first realized this would be a problem more than a year ago, and immediately asked what was being done to address the issue. Back then, the average answer was “hmm, you’re right, we never thought of that, but nothing will probably happen right now.” Today, with OpenDocument standardized and OOo 2.0 coming Real Soon Now, a solution is still missing.
What is a macro anyway?
From the end user point of view, macros today are used in OOo in two fundamental ways: they either extend the functionality of the whole program (on all the files it operates) or that of one specific document. This is similar to what happens with Web browsers. There are Firefox extensions, and there are JavaScript applets that run in Firefox as well as other browsers. The first are written for one specific browser, the second for a specific Web page. Users expect Web browsers to support JavaScript and HTML, but they don’t expect Internet Explorer or Opera to support Firefox’s extensions.
Most OOo macros that extend program functionality would be unneeded in other office suites, because other programs have their own ways of doing things. This category includes dictionaries, spelling checkers, word count, finding text in multiple files, and so on.
The other kind of macros are those which, for example, add buttons inside documents to check user input. Users will expect this kind of stuff to travel with the document, and be there no matter what program you open it with. A real-world example of this category would be an e-learning course based on OpenDocument questionnaires. Interactive documents of this kind should be fully usable across all OpenDocument-compliant programs.
StarBasic everywhere?
StarBasic is already established in StarOffice/OOo, has corporate backing today, and courses and books about it are available.
Generally speaking, OOo macros either use the OOo API or UNO (Universal Network Objects) dispatch calls. The first method gives developers full control and, being defined in Interface Description Language (IDL), would be accessible from a wide range of languages. A BASIC runtime should also be provided. The UNO method should be easier to implement after OOo 2.0 because a separate URE (UNO Runtime Environment) will be available.
From the outside, it could even seem that the simplest solution could be for KOffice to simply integrate the whole StarBasic interpreter from OOo, instead of writing a whole new one. However, even if there were no license problems, this would work only if the StarBasic interpreter code was modular enough to be easily ported, and if the developers committed to keep it that way.
To sum it all up, any of these solutions would require a lot of work.
In addition to this, at the API level the distinction between “program” and “document” macros is much more difficult to define and implement. Supporting only the latter would still require more or less the whole API. Nobody, starting from OOo developers, seriously recommends it.
What is the next step?
The most realistic solution seems to be to start preparing for a new alternative. Some KOffice developers, for example, have thought about integrating a Python interpreter. On the other hand, OOo 2.0 should support another easy way to implement simple logic (that is, our “document” macros) without any programming: the W3C XForms standard, which is not tied to any specific program. Why not go straight for XForms, and forget traditional macros altogether?
In the meantime, don’t put too much emphasis on those StarBasic skills in your resume.
