ApCoCoA-1:GUI

This page is meant for discussion regarding the design of a new GUI for CoCoA.

Language(s)

• C++ with some C for certain tasks
• 64bit clean
• GUI is based on qt4, since a GPL version is available on Linux, MacOSX, UNIX and MS Windows. A 4.0 release candidate is available as of 2005/06, a final version is expected around 2005/07 and a maintanance release, i.e. qt 4.0.1 should appear in the third quarter of 2005. qt4 is available in three different releases: A desktop, a light desktop and a version for the console only. Using qt provides portable classes to to threading, sockes, internationalisation, file operations, etc. which takes a lot of the burden of porting away from us.

Looks & i18n

Should be pretty much a clone of the old CoCoA-GUI, i.e. similar/identical menu-layout, shortcuts, and so on. We can use i18n, i.e. internationalisation with UniCODE, so one can translate the CoCoAGUI to foreign languages easily without touching the code or the need to recompile the programm. The tr()-macro in qt provides such a functionality which is nicely done and easy to handle for non-prgrammers, i.e. qt-linguist provides a gui for the task. The result of those translations is provided by a blob that just has to be copied into the build directory. It just works without recompilation. The language can be changed at runtime and is immediatly switched.

Internal Layout

There are some problems with the CoCoA 4.4 client:

• One can't interrupt a computation
• Since there is no way to interrupt a computation one cannot write a CoCoA-debugger
• There are no meaningful error messages from the parser
• Internally the code is a total mess, i.e. instead of using the parser directly we build a list/tree of cterms which are then parsed internally again. While doing that we do some really nonportable truly ugly optimizations [building an array of function pointers which we call with opcodes[funtion].
• The code is pretty much undocumented and the coding-style is utter crap. There are tons of macros that obsfucate the code and rewriting those is not an option since it is propably more work then a complete rewrite.
• The code is littered with old/unsused code, i.e. support for KDE, MacOS 9, DOS, etc. The qt-GUI build uses different C++ sources and makefiles. The qt2->qt3 port is a really big mess using a helper class from Trolltech.
• Licensing of the code is also a problem, since it isn't clear who wrote what.

What to do?

There have been plans to migrate the current CoCoAL to the new CoCoALib. Since the new CoCoALib is approcahing usability, I would consider it feasible to attempt such a port. I would suggest doing the following course of action:

1. Write a new parser. The grammar and lexer are fine but as mentioned above the internal workings of the CoCoA client are pretty much crap. Since the CoCoALib doesn't support all features that the CoCoAL needs (by design?, i.e. what about file operations, sockets, all non-mathematical stuff) I would suggest writing a CoCoAL2cpp compiler, that translates the CoCoAL to C++ using the new CoCoAL. For some details see [Lit 1]
2. Once the compiler works, one can easily write an interpreter by swapping out the code-creation to use CoCoALib directly. In addition to the regular interpreter one can also easily implement a debugger. We should also be able to provide proper error messages.
3. Wrapping a QT-interface around it is little work in itself since qt provides tools for rapid prototyping and most of the needed classes are quikly implemented (menus, shortcuts, MDI, ...)

Architecture

We should separate the qt-client from the computational kernel. There are a number of reasons to do that:

1. Modularity: less code duplication and reducred complexity
2. Asynchronus Development cycle: Due to 1) we can develop and test GUI and computational kernel idependently. Another added bonus is that GUI and computational kernel can be compiled using different modes, i.e. on MacOSX any GUI application can only be compiled in 32bit mode due to its hybrid 32/64 bit development model. Once the client wants to adress more than 4G of memory the 32bit client will fail. In 06/2005 this is not really an issue since there are few Macs with more than 4G ram (the dual models go up to 8G) but a year or two down the road 4G+ will be commonplace. Besides MacOSX Solaris also employes a hybrid 32/64 bit mode due to legacy support. As a consequence many libraries are not available in 64 bit per default and if they are available one has to spend some time to set things like LD_LIBRARY_PATH appropriatly for a given machine.

Extensability

PlugIn-architecture using loadLibraray (Linux, MacOSX, Unix) or LoadDLL (Win32)