A lot of attention has been given recently about the possibility of translating QuArK to the C/C++ language and/or porting it to another OS like Linux.

The current state of the Linux port idea is that, unless we need for a C++ version that new programmers could handle without having to learn Delphi first, the Linux port will wait until Borland releases its Delphi-for-Linux project (Kylix). However, that was scheduled for mid-2000 and is now cancelled.

Another posibility is Free Pascal, which is an alternative Pascal (and also Delphi) compiler. However, as this doesn't support Delphi packages (yet), this isn't an option at this time.

But the C++ translation could be needed just because it would let many new programmers with C++ knowledge enter the project. In this case we will have to be very careful about which OS-dependent the translated code uses and at which point the development of the Delphi version of the source has to be halted (because it is clear that we cannot indefinitely maintain concurrent C++ and a Delphi versions).

The 3rd reason we might want to translate to C++ is performance. Raw C++ code can run a bit faster than raw Delphi code (mainly because Borland's Delphi compiler is not good enough at optimizing...). This is however a relatively minor issue, as the performance bottleneck are found in the Python code emulation (mainly noticeable when you open the map editor and have to wait a little bit), and in the speed of the 2D drivers and hardware (for drawing the wireframe maps). The latter could be addressed by using complex bitmap caches techniques but not by translating the code to another language.

Another reason for a porting: it gives the opportunity to give the code a close look. Much of the code was not written with multiple game support in mind, and the codebase has become quite messy over the years. A complete clean-up would also add the opportunity to make the code more flexible, for instance related to different file formats.

If we decide that the C++ translation is not done for portability reasons then the easiest solution is to switch to BCB (Borland C++ Builder), which can compile both Delphi and C++ source code and shares Delphi's VCL (Visual Component Library). This would let us translate QuArK module-by-module as needed. Before we do so however we must make sure that BCB will be available in a Linux version nearly as soon as Delphi.

If on the other hand we decide we should make QuArK a real Free Software project, we have to see what solutions we have to translate it in such a way that it can be compiled by free compilers (GCC). This solution has the big advantage that QuArK would then be available on numerous platforms (e.g. the Mac) with little effort. Before we do so we must decide which widely-available GUI library we will target : Tk, Qt, others ?

In any case, keep in mind that most parts of QuArK are tightly integrated with each other... I mean, if you want to make, say, first an independant C++ version of QuArK where the model editor would be developed, and hope to translate the map editor from the "official" QuArK later as a block when everything works well, then forget about it. If you wanted even just to reproduce the current model viewer, you would have to port so many things from the current QuArK that you will end up with something that can already run the map editor's Python code... This means that you will have ported the map editor just by trying to port the model viewer ;-)

In conclusion, porting/translating has to be carefully prepared and it has to be done as fast as possible while the Delphi development is frozen. It cannot easily be done piece-by-piece. This would mean we need quite a big team of people working more or less nonstop, porting code from Delphi to C++, and at the moment (begin 2007) the development team is way too small.

Delphi is a system built on Object Pascal. The difference between O.P. and C++ is mostly syntax, but there are some substantive matters:

• case doesn't matter: string = String
• @variable gives the address of variable.
• The OP class system is based on RTTI, and has inherently greater flexibility than C++ (tho a lot less than Python).
• Casts are done with what looks like a C++ constructor. so if you want to cast a QObject as QFileObject, you write:  QFileObject(Obj)  where Obj is your QObject.
• OP constructors are by convention called Create, but can be called anything. So MyClass.Create('bozo') would probably be a constructor.
• A significant innovation is `properties' (basically the same thing as `ties' in PERL). A property is a class attribute that looks like an ordinary data member externally, but has associated with it  read  and  write  methods that are invoked at the appropriate times. So something like:  thing.size := 10;  can set off an arbitrarily large amount of processing, if  size  is a property of  thing 's class. Convenient for coding, but sometimes deceptive when reading the results ...
• HORRIBLE GOTCHA: in an  if begin ... end else ...  statement, if you put a semicolon after end, it will compile but the else block will never execute. [Note by Armin: wrong, a ';' before an 'else' will never compile] The semicolon rules are different than in C(++). Semicolons suck.
• OP doesn't use header files. The essential work of C(++) .h files is done in the  interface  section of a module, whereas the work of the .c(pp) files is done in the following  implementation  section. It wouldn't be a bad a idea to read the Delphi help on  interface ,  implementation  and  initialization .
• Programs, modules, etc end with  end.  This also sucks.
• In spite of the semicolons, in general, as far as I can make out, O.P. has everything you need to make real programs, without the annoying limitiations of 'textbook Pascal'.

The basic idea of Delphi is 'components'. These are modules that are installed into the IDE (by a command like Component|Install), where they appear as icons on as 'component palette'. Installed components can be clicked on and dropped into forms, or they can be invoked 'texturally' just by naming them in the declarings of a module.

There are squillions of components available on the internet, free, share & commercial. It seems to work well (about as smooth as PERL modules, modulo the advantages of the visual IDE).

As Delphi versions increment, the IDE gets more sophisticated, but if you start with Delphi v2 (occasionally available for free from various sources), the shift to v5 (current) is not daunting.

Aucun       - none

Ajouter     - to add



Charger     - to load



Dans        - in (SuivantDansGroupe = following in group)

Deplacer    - to move



Effacer     - to clear

Enfant      - child

Enregistrer - to save

Entete      - header

Etat        - state (TEtatObjet = object state type)



Fichier     - file

Frere       - brother (ModifeFrere = brother modified)



Lien        - link (LienFichierQObject = File Link QObject)

Lire        - to read



Modifier    - to modify



Ouvrir      - to open



Retirer     - to remove



SousElement - sub-element (Sous = under)

SousSelVide - empty sub-selection

Suivant     - following (SuivantDansGroupe = following in group)

SurDisque   - on-disk (Sur = on, over)



Taille      - size

Tout, Toute - all

Travail     - work, labor



Vide        - empty