Development Tools

While the initial design began, the team started searching for tools to use in the development process. The list we began with was enormous. From application frameworks to compilers to UML and CASE design tools, we churned out some interesting results - and we're still not done yet. One of the criteria for acceptable applications is that they must be freely available (preferably open source), feature rich, and stable.

Documentation Tools

There are three levels of documentation that we will generate - development documentation, SDK/Source Code documentation, and end user documentation.

Development Documentation

For ease of use, rich functionality, and platform availability, there was only one choice - OpenOffice.

SDK/Software documentation

For this we are using the all powerful Doxygen! What can I say, everyone loves this tool. A Doxygen guidelines document can be found in the Developers Documentation section. This provides a list of all tags and formatting requirements for using this tool when developing in the Qoole-AID code base. Did I mention that we LOVE this tool?

Please note that most developer documentation, including those outside of the SDK and C++ class documentation will also be generated with Doxygen. This will allow us to present all documentation in a single collection - HTML, RTF, MS Word, MS Help.

End User Documentation

As with development documentation, we have chosen OpenOffice for the end user documentation. This will provide us a complete set of tools that allow both the developers and end users to access all documentation with freely available tools.

Design Tools

[TBD]

Application Framework

This was the big one. Our secondary goal (first is to be the best, like Joe Bazooka Bubblegum) is to be cross platform. Our targets are Win32 (9x/NT/2000/XP), MacOS (9.x and X), and Linux (XWindows/GTK). In choosing how to approach developing an application for all three platforms without a lot of additional work, we compiled a list of several frameworks and utility toolkits that would keep us from writing 3 different front ends. In the end, we had 4 1/2 choices:

MFC: But isn't MFC for windows? Yes it is. But with the wonderful world of development, you have WINE. With WINE it would be possible to compile the MFC (yes it can be done) under Linux, and link to the WINE libraries. This would give us the application and make it available for Win32, Linux, and MacOS X - but not MacOS 9.x. The other drawback is that it's not free.

PowerPlant: From the good people who brought you CodeWarrior (Metrowerks) comes PowerPlant. PowerPlant is Metrowerks answer to MFC for the Macintosh. Unfortunately, I don't believe it supports Windows anymore (I believe it did at one point) and as far as I know is not available for Linux. Like MFC, it's not free - a big minus.

Java: It seems like everyone and their 2 year old is on the Java bandwagon except for me. While I truely believe that Java has it's rightful place in the world, I do not believe that it has reached the ability to be used in a CPU intensive enterprise sized application.

GTK: Quite a few applications have been run on both Win32 and Linux machines using GTK. But there were several minuses here. GTK support for windows has problems - quite a few in the way of GUI and user interaction. GTK doesn't support the Mac (at least not that I have been able to find). All applications using GTK, look like GTK - which is a problem since it gives an unfamiliar look and feel to Windows and Mac users.

wxWindows: This was probably the best framework that was evaluated. Not only does it support Win32, MacOS, and Linux, but the framework uses the native GUI and System calls - that means it looks like every other application running on the target OS. It has also been around for close to 10 years and has been used heavily for cross platform development. The BIG plus is that it can be used in conjunction with MFC (Win32 ONLY). Why did this become important? I personally have written many custom controls and extensions for MFC. It is also my preferred development environment. This means that the application can be rapidly prototyped (see quicker development cycle) and easily ported (in some cases as quickly as two weeks). This would also give the Qoole-AID team the chance to contribute custom additions to the wxWindows team while we develop our application.

In the end we chose wxWindows for it's supported targets, flexibility, ease of use, and the quick development cycle it will allow us. Because the GUI portion of the app will actually be very small (it's just an interface to the real application) and the fact that wxWindows code can be used along side of MFC, we get the best of both worlds.

Compilers

Choosing the compilers to use was pretty much a no brainer:

Win32:  Microsoft Visual C++ 6.0 with Service Pack 5,
Linux: GCC
MacOS 9.x: Metrowerks Codewarrior.
MacOS X: GCC or Metrowerks Codewarrior.

What will not be supported:

Borland: Any version (including Borland C++ Builder)
Ming/W: This is the Win32 port of GCC and the GNU libraries.
Delphi/Kylix: This is C++ folks, not PASCAL (yes, I have been asked this)
LCC-Win32: LCC is a ANSI-C only compiler.

If somebody wishes to create a project file or makefile for the Borland or Ming/W compilers we strongly encourage that - as long as they are willing to maintain and support those files.
 

Miscellaneous

Text Editors/IDE:

Feel free to use whatever you like - this really isn't an issue.