614 lines
33 KiB
HTML
614 lines
33 KiB
HTML
<!--startcut ==========================================================-->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>Integrated Software Development with WipeOut LG #30</TITLE>
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#A000A0"
|
|
ALINK="#FF0000">
|
|
<!--endcut ============================================================-->
|
|
|
|
<H4>
|
|
"Linux Gazette...<I>making Linux just a little more fun!</I>"
|
|
</H4>
|
|
|
|
<P> <HR> <P>
|
|
<!--===================================================================-->
|
|
|
|
<center>
|
|
<H1><font color="maroon">Integrated Software Development with <I>WipeOut</I></font></H1>
|
|
<H4>By <a href="mailto:gerd@softwarebuero.de">Gerd Mueller</a></H4>
|
|
</center>
|
|
<P> <HR> <P>
|
|
|
|
Programming under Linux means you have the choice between various powerful
|
|
development tools, such as <EM>gcc</EM>, <EM>gdb</EM>, <EM>make</EM> and a lot more. But most
|
|
of them are command-line tools and especially for beginners not easy to
|
|
handle. But this is only one side. The other important point is the source
|
|
code editor. Many people swear by <EM>vi</EM> (or one of its clones) - I don't
|
|
mind. But it's not enough to have a good editor, a compiler and a debugger.
|
|
Especially when you develop larger software projects you need a tool
|
|
to organize it efficiently, version control would be recommended and
|
|
for object-oriented languages a class browser is indispensable. Now you
|
|
have to get all these tools under one umbrella. I see mainly two ways to
|
|
resolve this problem: one is called <EM>(X)Emacs</EM> and the other is an <EM>
|
|
Integrated Development Environment</EM>. <P>
|
|
You can resolve nearly every problem with <EM>Emacs</EM> (may be in the near
|
|
future it will cook coffee for you ;)). It is not only an editor: you can
|
|
use it as mail tool, news reader, file system browser, debugger, compiler
|
|
and make tool. If you don't have a special feature it is possible to
|
|
extend <EM>Emacs</EM> to fit your needs. But in <EM>my</EM> opinion it does all these
|
|
things not very easily and intuitively. So I prefer the second way for
|
|
software development as mentioned above.<P>
|
|
In my understanding an <EM>Integrated Development Environment</EM> gives you a
|
|
graphical interface to the different tools and joins them in one environment.
|
|
The tools should help me to organize my projects and support the
|
|
code-compile-debug cycle. Advanced features are things like a GUI-builder,
|
|
documentation tool and maybe a CASE-tool like behaviour.<P>
|
|
Under Linux you have the choice between various IDEs. They are more or less
|
|
powerful and more or less expensive. In this article I'd like to introduce
|
|
one of them which is called <I>WipeOut</I>.<P>
|
|
<img src="./gx/mueller/blue_ball.gif"><B><FONT SIZE=4> History</FONT></B><P>
|
|
At the beginning there was just the idea to have some nice and easy to use
|
|
frontends for the main development tools of each C++-programmer under
|
|
Linux: <EM>gcc</EM>, <EM>gdb</EM> and <EM>make</EM>. We decided to use <EM>wxWindows</EM> [1] by
|
|
Julian Smart to program the GUI. The first versions of <I>WipeOut</I> were
|
|
developed with the OpenLook-variant of <EM>wxWindows</EM>. Later we changed to
|
|
<EM>wxXt</EM> by Marcus Holzem because most of the people didn't like
|
|
OpenLook. For basic data structures (container classes, strings, etc.) we
|
|
developed <EM>dmpack</EM> [2]. This library contains also features such as
|
|
streamable objects and remote method invocation, which are very important
|
|
to the communication between the various <I>WipeOut</I> components. The
|
|
communication part of <EM>dmpack</EM> is based on the <EM>socket++</EM>-library
|
|
by Gnanasekaran Swaminathan which provides an object-oriented interface to
|
|
sockets and pipes.<P>
|
|
<img src="./gx/mueller/blue_ball.gif"><B><FONT SIZE=4> Components and Features of <I>WipeOut</I></FONT></B><P>
|
|
Now <I>WipeOut</I> is a complete teamwork development environment for
|
|
C++, Java, Eiffel, Fortran and C projects. (Other languages may
|
|
follow.) At the present it consists of the following components:<P>
|
|
<UL>
|
|
<LI> <EM>Project Browser</EM> - the main window of <I>WipeOut</I>
|
|
<LI> <EM>Revision Browser</EM> - version control based on <EM>CVS</EM>, it supports remote repositories
|
|
and teamwork
|
|
<LI> <EM>e3-Editor</EM> - the central text editor with flexible syntax highlighting
|
|
<LI> <EM>Class Browser</EM> - supports Java and C++, used as source code navigator and
|
|
cross-referencer
|
|
<LI> <EM>Debugger</EM> - a frontend for <EM>gdb</EM>/<EM>jdb</EM>, supports threads
|
|
<LI> <EM>Make-Shell</EM> - a frontend for <EM>make</EM>, automatic makefile generation
|
|
<LI> <EM>Symbol-Retriever</EM> - a comfortable <EM>grep</EM> replacement for symbol searching in
|
|
a quantity of files
|
|
<LI> <EM>SurfBoard</EM> - our HTML-viewer to show help and man pages
|
|
</UL>
|
|
<P>
|
|
<I>WipeOut</I> is not a RAD-tool. This is because it's not a pure Java or C++
|
|
development tool. The editor, the project management, and the make shell work
|
|
also fine for other projects than C++ or Java. Besides it is hard to
|
|
decide for a special GUI-toolkit, which would be necessary for the C++
|
|
part. So we try to support the programmers with intuitive frontends for
|
|
various command-line tools and some important additional components, which
|
|
help for more effective programming.<P>
|
|
<I>WipeOut</I> is available for various platforms: <EM>Linux/i486</EM>, <EM>
|
|
Linux/m68k</EM>, <EM>Linux/Alpha</EM>, <EM>Solaris</EM>, <EM>HP-UX</EM>. All these
|
|
versions are fully compatible, so that you can use <I>WipeOut</I> for
|
|
multi-platform development. Furthermore there are porting activities for
|
|
<EM>LinuxPPC</EM> and <EM>Irix</EM>.<P>
|
|
Currently we provide <I>WipeOut</I> in two versions:<P>
|
|
<UL>
|
|
<LI> the free standard version: This version is free for non-commercial use, but it
|
|
has some restriction: there is no version control and a project can contain only
|
|
one module. All other components have the full functionality.
|
|
<LI> the <I>WipeOut</I><EM>Pro</EM> version: this version is unlimited and costs
|
|
$149 for commercial users and $79 for private users.
|
|
</UL>
|
|
<P>
|
|
<img src="./gx/mueller/blue_ball.gif"><B><FONT SIZE=4> Installation</FONT></B><P>
|
|
The Installation is not very difficult. To run <I>WipeOut</I> you need the following
|
|
packages:<P>
|
|
<UL>
|
|
<LI> wipeout-<VERSION>.tar.gz : this file contains <I>WipeOut</I> itself
|
|
<LI> wxxt-share.tar.gz : this is the GUI-library
|
|
<LI> wipeout-doc-<VERSION>.tar.gz : the <I>WipeOut</I> documentation
|
|
<LI> wipeout-tut-<VERSION>.tar.gz : the <I>WipeOut</I> tutorial
|
|
</UL>
|
|
<P>
|
|
You can obtain the packages from [4]. Then do the following steps:
|
|
<UL>
|
|
<LI> Create a new directory, where you want to install <I>WipeOut</I>
|
|
<LI> Copy the packages to this directory and unpack them with 'tar xvzf <package>'
|
|
<LI> Start the setup-program of <I>WipeOut</I> by typing './setup'. Follow the
|
|
instructions which the program will display. After finishing it will create
|
|
two small shell-scripts: You have to include 'wipeout.sh' with the 'source'-
|
|
command into your '.bashrc' or '.bash_profile' if you use <EM>bash</EM> or
|
|
'wipeout.csh' into your '.cshrc'-file if you use <EM>csh</EM>.
|
|
<LI> After opening a new shell, which uses the modified rc-file, you can
|
|
start <I>WipeOut</I> simply by typing 'wipeout'.
|
|
</UL>
|
|
<P>
|
|
<img src="./gx/mueller/blue_ball.gif"><B><FONT SIZE=4>First Steps</FONT></B><P>
|
|
After starting <I>WipeOut</I> you'll see the <EM>Project Browser</EM> to the left and the (empty)
|
|
editor to the right. The <EM>Project Browser</EM> is the central part of <I>WipeOut</I>. Here you
|
|
open the projects and start the other components.<P>
|
|
The first thing we do is to create a new project. Therefore we choose the
|
|
menu <B><I>'Project->New Root Module'</I></B>. A dialogbox opens and we have to
|
|
input the directory of the <EM>CVS</EM>-repository (see below) and the directory
|
|
of our new project. After confirming <I>WipeOut</I> asks us for adding the
|
|
'Makefile' and the '<arch>.def' file. We choose <B><I>OK</I></B>. What this files
|
|
mean we will see later. Now <I>WipeOut</I> creates a new module in the
|
|
repository and will initialize the project directory.<P>
|
|
After creating the new project we now have access to all the other
|
|
components. At first we will have a look at the <EM>Revision Browser</EM>.<P>
|
|
<img src="./gx/mueller/blue_ball.gif"><B><FONT SIZE=4>The <EM>Revision Browser</EM> - Part I</FONT></B><P>
|
|
<img src="./gx/mueller/rbw.gif"><BR>
|
|
<P>
|
|
The <EM>Revision Browser</EM> manages the modules and files of your project. A module
|
|
represents a directory and it groups the files logical. But a module can
|
|
contain submodules so that you can build a module hierarchy, which
|
|
represents your project.<P>
|
|
The <EM>Revision Browser</EM> shows this hierarchy in a GUI-element called <EM>browser box</EM>.
|
|
This box was inspired by a similar GUI-element of the <EM>NextStep</EM>-System
|
|
and it's a clever and easy way to display a hierarchy. Each listbox shows
|
|
one level of the hierarchy. The top of the hierarchy is shown in the most
|
|
left listbox. If you select an item the listbox to the right contains the
|
|
children of it. With the arrow buttons to the left and right of the box you can
|
|
scroll through the hierarchy.<P>
|
|
The files belonging to a module are shown in the right listbox. If you
|
|
double-click on an item the corresponding file will be shown in the editor.
|
|
To be exact: the file will be opened with the default application of
|
|
its category (see below). <P>
|
|
Every module has several properties. If you select a module and choose
|
|
<B><I>Edit->Info for File or Module</I></B> you get a dialog, where you can modify
|
|
the module properties. There are the following tabs:<P>
|
|
<UL>
|
|
<LI><B>Categories:</B> The files of a module are divided into categories. There
|
|
is an automatic assignment based on the file extension but you can do it
|
|
also explicitly. A file can be a member of more than one category. Categories
|
|
have mainly two meanings:<BR>
|
|
The first is, that each category represents a makefile symbol. All files of
|
|
a category are included in this symbol. In this way <EM>make</EM> knows how to
|
|
handle a file. An example is the default category 'CPP_source'. It includes
|
|
all files of the module with the extensions '*.C', '*.cc' and '*.cpp'. That
|
|
means normally they are C++-source code files. If you start to make a
|
|
module, all files of that category will be compiled with <EM>c++</EM> (as the
|
|
default C++-compiler).<BR>
|
|
As a second point you can assign one or more applications to a category. One
|
|
of them is the default application (this is normally the <I>WipeOut</I> editor
|
|
<EM>e3</EM>). If you double-click on a file in the filelist, this file will be
|
|
opened with the default application. If you select a file and click right
|
|
you'll get a small popup menu with all applications which are assigned via
|
|
the category to this file. By selecting one of them the file will be opened
|
|
with it.<P>
|
|
<LI><B>Directories:</B> Beside of its home directory you can assign other
|
|
directories to a module. These directories can have one or more of the
|
|
following meanings:
|
|
<UL>
|
|
<LI> Source : this is a directory where the debugger searches for source code
|
|
<LI> Header : this is a directory where additional header files are located, the
|
|
compiler will need this
|
|
<LI> Library : the compiler searches in this directory for libraries
|
|
<LI> Make : <I>WipeOut</I> starts a recursive make in this directory, when you
|
|
start to make the module
|
|
<LI> Browse : marks the directory for the <EM>Class Browser</EM> so that it will parse the
|
|
directory for classes
|
|
</UL>
|
|
The default properties of the module's home directory are 'Source' and 'Browse'.<P>
|
|
<LI><B>Options:</B> Here you can set some additional makefile options. If
|
|
you click on one of the buttons the editor shows the corresponding line of the
|
|
'<arch>.def'-file. You can set your compiler, compiler flags, include and
|
|
library paths, and libraries, which you want to link to your program.<P>
|
|
<LI><B>Tools:</B> Here you can set various tool properties. At present there
|
|
is only the make-command property: You can input here the make-command which
|
|
you like to use for making your project. The default is of course a simple
|
|
<TT>make</TT> but you may change it <TT>gmake</TT> or <TT>pmake</TT>.<P>
|
|
</UL>
|
|
<HR>
|
|
<B>WhatYouSeeIsWhatYouGet in <I>WipeOut</I></B><BR>
|
|
There is one point where <I>WipeOut</I> differs from many other programs: Mostly
|
|
settings will be persistent immediately, i.e. you don't need to save them
|
|
explicitly - real WYSIWYG. Just in some modal dialogs there are <B><I>OK</I></B>-
|
|
and <B><I>Cancel</I></B>-buttons, so that you have the choice to confirm or to cancel.
|
|
Furthermore you don't need to save property-changes you made for a module,
|
|
e.g. if you add a directory or category these items will be immediately visible
|
|
to all other components without saving and closing the dialogbox. We think
|
|
this kind of work is faster and intuitive.
|
|
<HR>
|
|
<P>
|
|
<img src="./gx/mueller/blue_ball.gif"><B><FONT SIZE=4>The aim of the game</FONT></B><P>
|
|
Now we know some things about modules and categories. It's time to turn back
|
|
to practice and produce a little chunk of code. In our example we will build
|
|
up a small <TT>String</TT> - class including the obligatory 'Hello World' - program.<P>
|
|
To create the source code for a module we have three possibilities:
|
|
<UL>
|
|
<LI> do it the old-fashioned and good way - open a new file in the editor
|
|
and hack the code into it
|
|
<LI> import existing files into the module
|
|
<LI> create class and method headers with the <EM>Class Browser</EM>
|
|
</UL>
|
|
<P>
|
|
We choose the last point, so that we can take a closer look at the <EM>Class Browser</EM>.
|
|
To open it just click on the third button of the <EM>Project Browser</EM>.<P>
|
|
<img src="./gx/mueller/blue_ball.gif"><B><FONT SIZE=4>The <EM>Class Browser</EM></FONT></B><P>
|
|
<img src="./gx/mueller/cbw.gif"><BR>
|
|
<P>
|
|
The <EM>Class Browser</EM> is bases on an incremental source code parser. That means your
|
|
code can be incomplete or wrong, but the <EM>Class Browser</EM> will scan it for classes,
|
|
methods, and members as good as possible. The <EM>Class Browser</EM> parses this project
|
|
directories which you marked as 'Browse' (see above). After building-up the internal
|
|
database the first time, only such files will be parsed again, which changed
|
|
or depend from changed files and new files. You have to tell the
|
|
<EM>Class Browser</EM> explicitly to update the class hierarchy with <B><I>Hierarchy->Update</I></B>
|
|
(or faster the corresponding toolbar button). But you must only update if
|
|
you changed a class or method declaration.<P>
|
|
Apart from the well-known browserbox, which is used here to show the class
|
|
hierarchy, the <EM>Class Browser</EM> has another <I>WipeOut</I>-standard GUI-element
|
|
- the <EM>panelbox</EM>.<P>
|
|
The development of the panelbox was necessary, because time after time there
|
|
were to many non-modal dialogs which showed important information. This
|
|
wasn't easy to survey. The panelbox is clearly structured and gives fast
|
|
access to various information without loosing survey. The panelbox consists
|
|
of one or more subpanels. You can assign the number and kind of the panels
|
|
with the small buttons in the top of it.<P>
|
|
The <EM>Class Browser</EM> has five different subpanels:
|
|
<UL>
|
|
<LI> Methods : shows the methods of the current class
|
|
<LI> Members : shows the members of the current class
|
|
<LI> Hotlist : shows the hotlist (see below)
|
|
<LI> All Classes : shows all classes of the hierarchy
|
|
<LI> All Methods : shows all methods of the hierarchy
|
|
</UL>
|
|
<P>
|
|
The hotlist is a collection of often used classes, methods and members, so
|
|
that you have fast access to them. With the menu item <B><I>Hotspots->Add
|
|
Hotspot</I></B> you can add the current class, method or member to the hotlist. A
|
|
double-click on a hotspot opens the corresponding file in the editor. This
|
|
is similar to all other listboxes. Beside of this you are able to control
|
|
the listboxes via keyboard: with the cursor keys, 'Home', 'End', 'PageUp'
|
|
and 'PageDown', but also with alpha-numerical keys. If you press a letter
|
|
the listbox cursor jumps to the first item beginning with that letter.<P>
|
|
But now we want to build our <TT>String</TT>-class: We do that with
|
|
<B><I>Edit->New Class ...</I></B>. We input the name of the class and press
|
|
<B><I>Insert In New File</I></B>. <I>WipeOut</I> will ask us several questions, but we
|
|
confirm all of them with <B><I>OK</I></B>. The editor shows us now a new header file
|
|
for our <TT>String</TT>-class. <P>
|
|
The next step is to add some methods. We do that with the <B><I>Edit->New
|
|
Method ...</I></B>-dialog. Simply input the method declaration as you know it
|
|
from C++/Java and set the editor cursor to the right places when <I>WipeOut</I>
|
|
asks you to do so. After writing some implementation code your source files
|
|
should look as follows:<P>
|
|
<B>Listing 1</B><P>
|
|
<PRE>
|
|
// $Id: mueller.html,v 1.2 2002/10/09 22:24:27 lg Exp $
|
|
// some comments ...
|
|
#ifndef _String_h
|
|
#define _String_h
|
|
class String {
|
|
protected:
|
|
char* _data;
|
|
public:
|
|
String(char *);
|
|
virtual String();
|
|
virtual String& operator= (char *);
|
|
virtual char* data() const;
|
|
};
|
|
#endif
|
|
</PRE>
|
|
<B>Listing 2</B><P>
|
|
<PRE>
|
|
// $Id: mueller.html,v 1.2 2002/10/09 22:24:27 lg Exp $
|
|
// some comments ...
|
|
#include <iostream.h>
|
|
#include <string.h>
|
|
#include "String.h"
|
|
String::String (char *data) {
|
|
_data = new char[strlen(data)+1];
|
|
strcpy (_data, data);
|
|
}
|
|
String::String() {
|
|
delete _data;
|
|
}
|
|
char* String::data() const {
|
|
return _data;
|
|
}
|
|
String& String::operator= (char* data) {
|
|
delete _data;
|
|
_data = new char[strlen(data)+1];
|
|
strcpy (_data, data);
|
|
return *this;
|
|
}
|
|
main() {
|
|
String str ("Hello ...");
|
|
cout << str.data() << endl;
|
|
}
|
|
</PRE>
|
|
Because we generated the class with the <EM>Class Browser</EM> we don't need to update the
|
|
class hierarchy explicitly. Beside of this the <EM>Class Browser</EM> added the files
|
|
'String.h' and 'String.cc' automaticly to the module in the <EM>Revision Browser</EM>.<P>
|
|
<img src="./gx/mueller/blue_ball.gif"><B><FONT SIZE=4>The <EM>Revision Browser</EM> - Part II</FONT></B><P>
|
|
Before we continue just a few words about version control for those of the
|
|
readers, who are not familiar with it. The repository (we set its directory
|
|
while creating the new project) is the central database of the version
|
|
control. All developers get the actual source code version from there. Each
|
|
developer has a local copy of this version (or a version of her/his choice)
|
|
and she/he can edit it.<P>
|
|
If the developer does a <EM>commit</EM> the local copy of the file goes into
|
|
the repository. Now all other developers have access to this new version of
|
|
the file. They have to <EM>update</EM> their local copy. If a developer made
|
|
changes at a file but didn't commit them yet and update this file now,
|
|
<EM>CVS</EM> merges the local copy and the actual version of the repository. The
|
|
developer will not loose his changes. After updating the local copy may
|
|
contain <EM>conflicts</EM>. That means the changes of the developer collide
|
|
with the changes from the repository version. The developer has to resolve
|
|
these conflicts (with support of the <EM>e3</EM>) before committing the file
|
|
again.<P>
|
|
If you take look at the file list of the <EM>Revision Browser</EM>, you will see there four
|
|
files: 'Makefile', '<arch>.def, 'String.h' and 'String.cc'. All these items
|
|
have a '[n]' at the beginning and empty parentheses at the end.
|
|
The signs within the brackets have the following meanings:<P>
|
|
<UL>
|
|
<LI>+ : the file is up-to-date
|
|
<LI>< : you need to 'Commit' the file
|
|
<LI>> : you need to 'Update' the file
|
|
<LI>x : there could be conflicts with other developers
|
|
<LI>X : there is a conflict within the file
|
|
<LI>n : the file was locally added
|
|
<LI>- : the file was locally deleted
|
|
<LI>? : no status information available
|
|
</UL>
|
|
<P>
|
|
Beside of the conflict symbols the signs have the same meaning for modules.<P>
|
|
The parentheses after the file name contain the version of the local copy.
|
|
If we select our module and commit it with <B><I>Revision->Commit File or
|
|
Module</I></B> the version numbers of the files change to '1.1' and the status
|
|
changes to '+'.<P>
|
|
Especially on team development the status of a file or module can change
|
|
every time. You have three possibilities to keep the <EM>Revision Browser</EM> up-to-date
|
|
(<B><I>Project->Module Properties</I></B>):
|
|
<UL>
|
|
<LI> on item select: status update each time you click on a file or module
|
|
<LI> on tool select: status update each time you select the first button
|
|
of the toolbar
|
|
<LI> timer interval: status update every <EM>x</EM> seconds
|
|
</UL>
|
|
<P>
|
|
Note that each status update causes a <EM>CVS</EM> command. If you work with
|
|
remote repositories but you have only a poor connection to it, it's
|
|
recommend to choose the second possibility.<P>
|
|
<I>WipeOut</I> has a lot other features for version control and team work, e.g.
|
|
you can create version branches for files and modules, you can merge
|
|
these branches again and you can assign symbolic names (tags) to versions.
|
|
You have various possibilities to import existing projects (with or without
|
|
<EM>CVS</EM>). All these things are described in the <I>WipeOut</I> documentation and
|
|
with a little patience it should be easy to find them out.<P>
|
|
Before we now compile our small project we'll take a look at the editor.<P>
|
|
<img src="./gx/mueller/blue_ball.gif"><B><FONT SIZE=4>The <EM>Text-Editor</EM></FONT></B><P>
|
|
<img src="./gx/mueller/e3.gif"><BR>
|
|
<P>
|
|
The editor is a central component of <I>WipeOut</I>. You use it for source code
|
|
editing and whenever another component needs to show a file or to know a
|
|
source code position it uses the editor. This is one of the basic concepts
|
|
of <I>WipeOut</I>: only one central text editor.<P>
|
|
This causes a very high integration of the editor into the development
|
|
environment. That's why it is not possible to use another editor within
|
|
<I>WipeOut</I>. This seems to be a great disadvantage because the most of the
|
|
developers have their own favourite editor and it's not easy to turn to another
|
|
one. But this way it is possible to integrate such features as the symbol
|
|
completion: If you press 'Ctrl-.' in the editor it will try to complete the
|
|
word you are writing currently. Therefor it uses the database of the
|
|
<EM>Class Browser</EM> and looks for a matching class, method or member name.<P>
|
|
Another nifty feature is the integrated man page viewer: If you select a
|
|
symbol in the <EM>Text-Editor</EM> and press 'Ctrl-m' the <EM>SurfBoard</EM> will show the related
|
|
man page if there is one. In the near future we will extend this to info
|
|
pages and external HTML-documentations.<P>
|
|
<I>Syntax Highlighting</I><P>
|
|
The highlighting of syntactical elements increases the readability of source
|
|
code. The <I>WipeOut</I>-editor uses <EM>regular expressions</EM> to do that. The
|
|
syntax is similar to the 'grep'-command. The documentation of <I>WipeOut</I>
|
|
contains a general overview of the meta-symbols. This kind of highlighting
|
|
slows down the editor a little bit but it gives you the flexibility to
|
|
create your own highlighting style.<P>
|
|
A <EM>style</EM> is a set of a regular expression, a file pattern, a color and
|
|
a font. Each style highlights a special syntactical element specified
|
|
by the regular expression in the given color and font, but only in those
|
|
files, which match the file pattern. You can create and edit styles with
|
|
<B><I>Properties->Highlighting</I></B>. <P>
|
|
The editor has default styles for C++, Java, Objective-C, LaTeX and HTML.
|
|
You can use this styles as they are, but you can also change them. There is
|
|
a lot of space for experiments.<P>
|
|
Beside the styles there are some other parameters: various colors, tabs,
|
|
undo-depth, font sizes, etc. Finally the editor is very easy to use, so
|
|
that there shouldn't be to big problems. <P>
|
|
<img src="./gx/mueller/blue_ball.gif"><B><FONT SIZE=4>The <EM>Make-Shell</EM></FONT></B><P>
|
|
<img src="./gx/mueller/make.gif"><BR>
|
|
<P>
|
|
But now back to our mini-project: after creating files, adding them to a
|
|
module, working with the <EM>Class Browser</EM> and the <EM>Text-Editor</EM> it's time to compile the
|
|
program.<P>
|
|
<I>WipeOut</I> uses <EM>make</EM> to compile your projects. Normally all necessary
|
|
files will be created automaticly based on the module information. Each
|
|
module has three different parts for the makefile: <P>
|
|
<UL>
|
|
<LI> <EM>Makefile.inc</EM>: contains various symbol definitions, e.g. each
|
|
category gets a symbol, which contains the files of the category. The
|
|
makefile uses this symbols to determine, which files to compile for a
|
|
special target. This file will be updated continuously be <I>WipeOut</I> and you
|
|
should not edit it.
|
|
<LI> <EM><arch>.def</EM>: contains platform depending parameters. '<arch>'
|
|
will be replaced by the OS-name, e.g. Linux. When you develop a project
|
|
with <I>WipeOut</I> across various platforms this file helps you to make the
|
|
platform specific compiler settings.
|
|
<LI> <EM>Makefile</EM>: This is the makefile itself. It includes 'Makefile.inc'
|
|
and '<arch>.def'. You can edit it for adding other than the default targets.
|
|
The <EM>Make-Shell</EM> will call <EM>make</EM> with this file. The makefile contains default
|
|
rules to compile C-, C++-, Java- and flex-sources. It has targets to
|
|
build C/C++- and Java-programs and static or shared libraries.
|
|
</UL>
|
|
<P>
|
|
To start <EM>make</EM> we open the <EM>Make-Shell</EM> with the 5th button of the <EM>Project Browser</EM>. This
|
|
dialog has only a few elements: the <B><I>Start</I></B>-button to start <EM>make</EM>, an
|
|
edit field to set a special target (an empty field means the default target -
|
|
'cplusplus') and two checkboxes. Normally <EM>Make-Shell</EM> shows only compiler errors
|
|
and warnings in the lower listbox after <EM>make</EM> has finished. If we check
|
|
'All Lines', we get all the <EM>make</EM> output in the listbox. If we check
|
|
<B><I>Progress Window</I></B>, a small output console opens while compiling and shows the
|
|
original <EM>make</EM> output.<P>
|
|
We compile our program simply by pressing <B><I>Start</I></B>. After finishing the
|
|
error listbox shows us a warning about a virtual constructor. We click on
|
|
the warning and the editor cursor jumps to the error line. We recognize
|
|
that the constructor should be a destructor and so we complete the
|
|
implementation and declaration with the tilde-letter. We compile again and
|
|
now everything should be okay.<P>
|
|
To test our program we open the shell of the <EM>Project Browser</EM> and input the name of our
|
|
module because this is the name of the program. The output is, oh wonder:<P>
|
|
<TT>Hello ...</TT><P>
|
|
As the next step we extend our project somewhat. Therefor we add two
|
|
methods:<P>
|
|
<B>Listing 3</B>
|
|
<PRE>
|
|
String& String::operator+= (const String& rhs) {
|
|
char* buf = new char[length()];
|
|
for (int i=0; i<length(); i++)
|
|
buf[i] = data()[i];
|
|
for (int i=0; i<rhs.length(); i++)
|
|
buf[length()+i] = rhs.data()[i];
|
|
delete _data;
|
|
_data = buf;
|
|
return *this;
|
|
}
|
|
int String::length() const {
|
|
return strlen(data());
|
|
}
|
|
</PRE>
|
|
We modify the main function as follows:<P>
|
|
<B>Listing 4</B>
|
|
<PRE>
|
|
main() {
|
|
String str ("Hello");
|
|
str += String (" from WipeOut.");
|
|
cout << str.data() << endl;
|
|
}
|
|
</PRE>
|
|
After recompiling and running the program we now get a 'Segmentation fault'
|
|
and we have no idea why. This is the right time to use the debugger.<P>
|
|
<B>The debugger</B><P>
|
|
<img src="./gx/mueller/bugview.gif"><BR>
|
|
<P>
|
|
We start the debugger with the fourth button of the <EM>Project Browser</EM>. The interface
|
|
consists of similar elements as the <EM>Class Browser</EM>: the browserbox and the
|
|
panelbox. The panelbox has five different subpanels:<P>
|
|
<UL>
|
|
<LI> Breakpoints : shows all breakpoints
|
|
<LI> Stack : shows the current execution stack
|
|
<LI> Sources : shows all source related to the program
|
|
<LI> Expression : shows a special variable expression
|
|
<LI> Threads : used when debugging threads
|
|
</UL>
|
|
<P>
|
|
We arrange the panelbox for our needs: we add the 'Sources'-panel to the
|
|
two default panels 'Breakpoints' and 'Stack' by clicking on the small
|
|
'plus'-button.<P>
|
|
Now we load the program with <B><I>Session->Load Executable</I></B>. After that
|
|
the 'Source'-panel should show all source files related to the program.<P>
|
|
The browserbox is used to show variable values. The first listbox shows per
|
|
default all local variables. If you click on an item, the next level shows
|
|
the value or the components of it. This way you can easy browse classes,
|
|
structures and arrays. After every action the debugger refreshes the
|
|
variable values automaticly.<P>
|
|
If you like to inspect a variable, which is not shown in the browserbox at
|
|
the moment, just mark it in the editor and choose <B><I>Inspect Variable</I></B>
|
|
in the toolbar of the debugger. Now the first list of the browserbox
|
|
contains the variable.<P>
|
|
Normally the debugger resolves data structures automaticly, so that you
|
|
always get the correct values, e.g. it shows the content of a pointer and
|
|
not the pointer value itself. But sometimes this is not possible, e.g. if
|
|
you declared an array of integer-pointer as '<TT>int**</TT>'. To get the
|
|
items of the array you have to cast the type with <B><I>Inspect->Change/Cast
|
|
Variable</I></B>. <P>
|
|
With <B><I>Inspect->Move Variable to Top</I></B> it is possible to move a variable
|
|
from a lower level of the hierarchy to the top, so that you don't need to
|
|
browse through the whole hierarchy to get the value of the variable.<P>
|
|
Because we've got no idea what's wrong with our program, we simply start it
|
|
with <B><I>Run->Run</I></B>. This causes a 'Segmentation fault' again, but after
|
|
we have confirmed the messagebox the editor colors the error line with red.
|
|
We've got an error in the method <TT>String::operator+=</TT>.<P>
|
|
Before we correct the error we should kill the program with <B><I>Run->Kill</I></B>.
|
|
To know what's going on in the method we want to find out what the
|
|
method <TT>data</TT> does. We use the <EM>Class Browser</EM> as <EM>cross-referencer</EM> to find
|
|
the implementation of this method. Therefore we mark <TT>data</TT> and choose
|
|
<B><I>Edit->Search Symbol</I></B> in the <EM>Class Browser</EM>. Now the editor shows the source
|
|
code of the method <TT>data</TT>. We see, that the method doesn't do anything
|
|
exciting, only returning the <TT>_data</TT>-pointer. We go back to the
|
|
<TT>String::operator+=</TT> method, take a closer look on it and recognize
|
|
that we've allocated not enough memory for <TT>buf</TT>. So we modify the
|
|
first line as follows:<P>
|
|
<PRE>
|
|
char* buf = new char[length() + rsh.length()];
|
|
</PRE>
|
|
We compile and run the program again and everything is fine. But we can't
|
|
see the output. We resolve the problem with <B><I>Inspect->Program Console ...</I></B>.
|
|
This opens a small console and after starting the program again, we see
|
|
the output:<P>
|
|
<TT>Hello from WipeOut.</TT><P>
|
|
The debugger has of course a lot of more features than explained above. Besides
|
|
of <B><I>Next</I></B>, <B><I>Step</I></B> and setting breakpoints it supports also threads.
|
|
It is recommended again to read the documentation about it.<P>
|
|
Beside of the <EM>Symbol-Retriever</EM> and the help browser <EM>SurfBoard</EM> now you touched all the
|
|
components so that you've got a first impression the way <I>WipeOut</I> works.
|
|
Of course we develop <I>WipeOut</I> with <I>WipeOut</I> and we find that it very
|
|
increases our productivity and makes it easier to program than just using
|
|
a simple text editor. Finally some words about extending <I>WipeOut</I>.<P>
|
|
<img src="./gx/mueller/blue_ball.gif"><B><FONT SIZE=4>Writing own <I>WipeOut</I> components</FONT></B><P>
|
|
At this time <I>WipeOut</I> contains only the most important components of our
|
|
opinion. There may be a lot of other possibilities, e.g. many people may
|
|
wish a GUI-builder. We can't and we don't want to do all that alone. So we
|
|
have created the <EM>WDK</EM> - the <I>WipeOut</I> Development Kit, which allows you
|
|
to develop your own components. This interface gives you access to
|
|
important functions of <I>WipeOut</I>, e.g. showing a file in the editor or
|
|
adding a file to a module.<P>
|
|
If you like to program such components you only need to download the
|
|
<EM>WDK</EM>-package from [4]. Apart from the documentation the package contains
|
|
<EM>DmPack2</EM>, <EM>socket++</EM>, the <EM>wxXt</EM> header files, a simple
|
|
example component and <EM>SpellMaster</EM> - a frontend for <EM>ispell</EM>. <P>
|
|
I hope you've got a rare overview about <I>WipeOut</I> and its possibilities. If
|
|
you have questions, comments or wishes, write us.<P>
|
|
<TABLE>
|
|
<TR>
|
|
<TD ALIGN=LEFT><FONT SIZE=5>Resources</FONT></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN=LEFT>
|
|
[1] <A HREF="http://web.ukonline.co.uk/julian.smart/wxwin">http://web.ukonline.co.uk/julian.smart/wxwin</A> -
|
|
wxWindows/wxXt by Julian Smart and Marcus Holzem</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN=LEFT>
|
|
[2] <A HREF="ftp://ftp.virginia.edu">ftp://ftp.virginia.edu</A> - socket++ by Gnanasekaran Swaminathan</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN=LEFT>
|
|
[3] <A HREF="http://www.softwarebuero.de/dmpack2.html">http://www.softwarebuero.de/dmpack2-eng.html</A> - DmPack2</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD ALIGN=LEFT>
|
|
[4] <A HREF="http://www.softwarebuero.de/wipeout.html">http://www.softwarebuero.de/wipeout-eng.html</A> - <I>WipeOut</I></TD>
|
|
</TR>
|
|
</TABLE>
|
|
|
|
<!--===================================================================-->
|
|
<P> <hr> <P>
|
|
<center><H5>Copyright © 1998, Gerd Mueller <BR>
|
|
Published in Issue 30 of <i>Linux Gazette</i>, July 1998</H5></center>
|
|
|
|
<!--===================================================================-->
|
|
<P> <hr> <P>
|
|
<A HREF="./index.html"><IMG ALIGN=BOTTOM SRC="../gx/indexnew.gif"
|
|
ALT="[ TABLE OF CONTENTS ]"></A>
|
|
<A HREF="../index.html"><IMG ALIGN=BOTTOM SRC="../gx/homenew.gif"
|
|
ALT="[ FRONT PAGE ]"></A>
|
|
<A HREF="./bennet.html"><IMG SRC="../gx/back2.gif"
|
|
ALT=" Back "></A>
|
|
<A HREF="./nelson.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
|
|
<P> <hr> <P>
|
|
<!--startcut ==========================================================-->
|
|
</BODY>
|
|
</HTML>
|
|
<!--endcut ============================================================-->
|