Integrated Development Editors (IDE's) under Linux.

Written by Mike Andrew

Regardless of OS or platform or embedded engine: all code developers use tricks of trade to inter-relate the multitude of files, source codes, shells and other objects that make up their 'project'. Even in the simplest case of a single C file with no header, a Makefile (or it's substitute) must exist, a means of 'loading' the resulting "program", and a means of 'running' that program. The incantations required are the same for cross compilers, the same for embedded engines, as they are for a full featured supporting platform such as the Linux Operating System. The verbiage for each type of 'system' is, obviously, different, but the needs and incantations, the same.

In it's simplest constructs using Linux terminology

edit
make
(dot)(slash)execute

One methodology that has been used since Fortran (grin), is to simply use multiple instances of terminal windows,  and have therefore, various editing files in view. Eg a C source, it's header, a Makefile, a command line. This approach works equally well under a gui (such as KDE), or plain vanilla ALT-Fx multiple logins. For many purposes this approach is best. It's drawback is, there is no automation of the relationships between various 'objects' making up the various views, except in the mind of the programmer.

An IDE, helps to package these various objects into a single project. The degree to which the IDE does this, is proportional to it's complexity, and hencely, it's difficulty to manage.

Enter the GUI Dialog.

Dialog Panels are the premier reason behind guis. They offer, or can offer, idea-tokens of what it is the program requires from the user. They offer 'in your face' selections of radio buttons, choices, and user input statements. Each of these items are loosely termed 'widgets'. Little wonder, an IDE widget creator is a desirable item. Particularly if that IDE can interface, or automate, the connexion between generating these visible widgets and the underlying controlling program.

In Linux, I will mention FOUR (4) different IDE's. Each, to varying degrees, accomplish some, or all, of the above task.

---

Kdevelop

Kdevelop is the killer app of it's class. It is THE all-singing all-dancing RDT (rapid development tool) for K applications. See here for the SxS.

If you intend for your application to run as part of the KDE Desktop Environment. Kdevelop will give you acces to all the 'features' of that environment, with bells on. Be aware, that like all Window Managers,  KDE itself does not preclude use of any gui application, be it K inspired or otherwise. The advantage of Kdevelop, is it's inherent access to K features.

The second (and major) advantage is that Kdevelop is a one-stop-shop. It generates all source, all widgets, all documentation, runs (and debugs) the resulting binary(s). There is NO other product 'out there' that does this. Not under Gnome, nor anything else.

If you want a one stop shop, unitary, self-contained IDE , use Kdevel, work the learning curve, and be aware that your application might be usable only under KDE (for the most part).

The one big drawback of Kdevelop is it's enormous bloat. It is simply gigantic, both in produced source, and in it's own right. While improving in documentation, it remains a large learning curve to get that first app out the door. There are alternatives, and for many occasions the generated source of Kdevelop is simply unnaceptable (in it's length, size and complexity).


Code Crusader

Code Crusader alias jcc is THE premier source code editor/manager. It is loosely modelled on the commercial product, MetroWorks CodeWarrior.

Editing source is such a basic requirement, that there are any number of means of achieving it, each with it's own religion. vi, joe, emacs, Kedit, Midnight Commander, Kwrite, name your poison. (The *best* editor in this author's never-humble opinion, is Winedit, a Windoze only editor, _specifically_ designed for *nix).

What few editors can do, is associate the various source files. Emacs can, but with an unnecessary learning curve on your part, and an obtuse language set to achieve it. The answer is Code Crusader. It is, the best in it's class. It is THE IDE for Source code. See here for the SxS.

Code Crusader 'understands' C, Java, Perl and C++, as well as, generically, most language formats. The impact of this is that, somewhat like Brief (an inspired CP/M code editor) colour highlighting of the syntax (as an example) is a feature of jcc.

Jcc does a fair to muddling job of generating (Makeing) and running the resultant output. The difficullty lies in the nature of Linux Operating systems and their makefiles. There are too many variable conditions such as the location of specific libraries, the names of compilers etc, to garantee a one stop shop. Some, but not extensive, tweaking of Code Crusader's Makefile(s) are normally required. This is not a criticism. it is a reflection of the generic nature of Jcc, that it can, with tweaking, be set to any environment, including, that of KDE.


GUI WIDGET EDITORS

Separate to Kdevelop itself is the widget editor it employs. Specifically, QT designer. For further info, read the SxS. It is unlikely you will use this gui maker outside of the K environment.

Xforms Alias Forms Designer

Xforms has been extensively used for some years. It is a common tool found on Sun CGI. See here for the SxS

Forms Designer is untuitive and very easy to apply. While the function library underneath is quite extensive, most functions follow some basic syntax rules to the point where you can guestimate the requirement. eg fl_set_object_color(object,FL_RED); is pretty explanatory. This means that resorting to the reference documentation every 10 seconds is not necessary.

The generated source is a single C struct {}. It is very straightforward to integrate it into the underlying controlling code written by you.

And finally, the event callbacks (button pushed etc), follow simple syntax rules.

The drawbacks to Xforms are

• it is bloat. Nearly everything in the lib is included in the resulting binary. Used or not. Howver, bloat is relative. The overall code is not huge.
• It is X specific. It only operates under X(Free). Not an issue if you don't port.
• The resulting gui displays are klunky. They are based on the motif widget set of yesteryear and do not fit well into the leaner meaner look of today.
• It is C only source code. Gui designs, gui widgets, lend themsevles to C++ oops classes.
  

However, combined with Code Crusader above, you have a powerfull IDE in your toolchest.

FLTK, fulltick to it's friends, is the next generation Xforms. It generates C++ code and, creates widget classes. For more information see the SxS