[DE | EN | FR | JA | ES]

Welcome to Georg's Brave GNU World. This month I got several small projects covering a relatively wide spectrum of applications. I'll begin with a very interesting mail reader.

Sylpheed

The Emacs based mail readers have problems handling attachments properly, are pretty heavy-weight and they require starting emacs in order to read mail. The other GUI-oriented mail programs have interfaces that the author felt were hard to get used to, sometimes they don't support threads, don't know about the existence of other mail readers or some features can't be controlled via the keyboard. Everyone who has thought similar things in the past might want to give Sylpheed a try.

The advantages of Sylpheed are pretty impressive. Based on the GTK+ toolkit it has a very intuitive interface. Its capability for filtering mail and display it in threads helps you keep your mail organized. Of course it does support multipart MIME and contains an integrated image viewer. X-Faces are supported as are "clickable URIs." But despite this heavy GUI reliance, everything can be done with the keyboard, as well.

An extremely positive feature is the XML-based address book - this way it is guaranteed to be portable and available for other applications. The mail folders are portable, as well. Since they are saved in the MH format, they can be used by other mail readers like Mew.

On top of this Sylpheed can read (but not write) news and it does support calling the external program fetchmail and procmail to retrieve mail. Outgoing mail can be collected in a queue before sending.

Sylpheed is rather young, so there is still a pretty long TODO list that contains IMAP4, LDAP, PGP/GPG support, SSL, compression of mail folders and more. It also needs some work on the English localisation - but since it is gettext based this shouldn't be too hard. Debian users can install Sylpheed directly from the given address; everyone else isn't worse off since it does support autoconf/automake.

If you are unhappy with your mail reader at the moment, you should definitely consider giving it a try.

Xzgv

Xzgv can be controlled completely using mouse or keyboard and it only uses a single window for selecting and displaying images - no more of the "window zoo" that some image viewers tend to create. Since it has been written based on the GTK+ toolkit with conscious unawareness of GNOME or KDE it can be used anywhere without a problem and has a great responsiveness as well as a good usability.

The author asked me to emphasize that writing a good image viewer is not as trivial a task as some people appear to think. Of course it is not a highly complicated task to "just display some image." But creating a general image viewer that "does things right" requires solving some non-obvious problems.

Xzgv is already very much finished - plans for further development are limited to maybe get away from the Imlib 1.x library and optimize viewing really big pictures.

As it is licensed under the GNU General Public License, I can definitely recommend it without any bad feelings.

I'll continue with a rather special program that has recently joined the GNU Project.

Solfege

A remarkable feature is that it is extensible via "lesson files" in ASCII format, so that people with knowledge about music education can easily add their own lessons. It happens that writing more of these files is one of the most urgent tasks at hand.

In the long run the author would like to reimplement large parts of the program as the solutions chosen have proven to be unsatisfactory to him. In doing so the help of people with experience in OSS programming would be very welcome.

it should also be mentioned that the obvious target audience, music students & others interested in training their hearing should not expect too much from this program at the moment because Solfege V1.0 is still a bit away.

The next project has also made its way into the GNU Project and comes from the school area, as well.

Ggradebook

It is based on the GTK+ toolkit and can optionally be compiled with GNOME support. Ggradebook can handle grades in percentages, abstract numerical or alphabetical form; the last two can be matched to percentages automatically and their scales are customizable.

A current problem is that with percentages and the alphabetical grades it is not yet possible to use a "+" or "-" to raise/lower the grades - this can only be done for numerical grades. Further plans involve an import/export filter for similar programs, internationalisation and more features. Additionally, although the interface does allow accessing all functions it could definitely be improved in terms of user-friendliness.

The biggest difficulty the authors are facing at the moment is the lack of feedback - they need more. So all readers who could use something like it are encouraged to give it a try and tell them what you think.

The next three projects are probably are definitely more on the developer's side.

Common C++

Basically, the Common C++ project starts where the ANSI Std C++ library stops. The goal is to create a portable class library that provides functionality for tasks like abstract threading, sockets, serial I/O and a persistent class-serialization on Posix and Win32 systems.

Most of this functionality is already provided by single, unrelated libraries. For David Sugar, the advantage of Common C++ lies in the consistent structure for all these tasks. It is also very portable and instead of including everything in one big library, Common C++ uses different libraries for the different systems. This makes it possible to write the libraries custom fitted to the machine and system which reduces the overhead. At the same time Common C++ applications will work on both architectures.

As far as the compilers are concerned, it is very tolerant and supports several of the C++ compilers not obeying the standards - although he believes that with increasing standardization this becomes neglegible.

As most developers know, pretty much every Unix implementation has its own thread implementation that usually does not conform with the standard. For these Common C++ provides an extensive amount of tests during configuration time to assure they can be abstracted in a clean way. Although it does not yet cooperate directly with GNU Pth (GNU Portable Threads, see issue #1 of the Brave GNU World), it should already be able to work with it's pthread emulation. For the future it is planned to provide native GNU Pth support.

Currently a "rewrite" for version 2.0 is scheduled to happen this autumn in order to remove anachronisms for old C++ compilers. Additionally it is planned to support more platforms (BeOS) and as far as functionality is concerned, a library for network protocols will be implemented. The lack of this network protocol library is the biggest weakness of Common C++ right now, as far as David Sugar is concerned. In the long term perspective he expects to take a more administrative role as there is a very active community of developers for this project. He especially wants to see Henner Zeller and Gianni Marianni mentioned who put a lot of work into the latest release.

The license chosen for this project is the GNU General Public License with a few extra terms that are a bit like the Guile license. This places it between GPL and GNU Lesser General Public License as far as the granted rights & freedoms are concerned. Since this has led to some confusion in the past, version 2.0 will probably be distributed under the LGPL.

As of April 2000, Common C++ is an official GNU Project which isn't surprising as it is already the basis for several Free Software projects like Bayonne (see Brave GNU World issue #16).

GNU marst

The project implements the complete Algol 60 programming language as specified in "Modified Report on the algorithmic Language Algol 60" [11]. As this language doesn't really change all that much, the author's current task is to write a front-end shell that makes handling easier for the user. If you happen to have free Algol 60 programs: the author is looking for programs of any kind at the moment.

Gengetopt

This is a very useful tool for every C/C++ programmer, since it does the rather tedious but very important job of parsing the commandline for the programmer. The programmer simply specifies the desired options, whether they are mandatory or optional and whether they require a parameter. The C source code generated by gengetopt is added to the program and a simple function call validates and evaluates the commandline.

In the tradition of the Brave GNU World, I'd like to discuss something not directly related to software as the last project.

OpenTheory

The main site [13] offers a coordinative hub driven by a web based tool that allows exchanging thoughts and ideas. Projects can be started online and documents can be made available for discussion. All text is transmitted in ASCII format and stored in a MySQL database. The pages are based on PHP3 which makes them dynamic to the extreme.

Each of the projects has its own mailing list that can be posted to over the web interface. Additionally similar projects can be linked and share their mailing lists.

The only thing Stefan Meretz is missing right now is a mail interface to control the OpenTheory functions - at the moment documents cannot be submitted via mail.

The project has already been applied to some rather interesting tasks. The Oekonux project (Brave GNU World, issue #18) sprang to life there but people also used it to discuss and improve their talks for the LinuxTag in Stuttgart, Germany on it.

The OpenTheory project itself - which refers to the software providing the functionality - is licensed under the GNU General Public License and being at version 0.4 other developers are still very much invited to join.

see ya later...

But as usual I would like to encourage you to contact me with new projects, ideas, question and suggestions [1].