# &kdevelop; Documentation

## Overview: Development on UNIX

From the beginning, UNIX has maintained two very different development paradigms. One is the world of system programming languages, where the source code is compiled to machine code by a compiler. The programming language C is an example for this. UNIX was the first operating system kernel to be written in a high level language instead of assembler which was common before that time. The other paradigm is the world of scripting languages which began with the shell which was at the same time the user's interface to the operating system and a very high level programming language. Elementary building blocks in a shell script are small utility programs like `grep`, `sed` and `find` which do some tightly defined job and which are connected to each other via pipes.

As time has gone by, both worlds have evolved. While C is still used mainly as a system programming language, C++ as a variant of C enriched by object-oriented and genericity extensions has found its place for the development of complex applications in the 1990's. FORTRAN77 and Ada still have their stronghold in numerical applications.

In the scripting area, there has been a shift away from the shell, which suffers from portability concerns, to languages which unify all commonly needed functionality in their standard libraries, while still being able to interface to the outside through pipes when necessary. &perl; has become popular as a text processing and system administration language. In the beginning of the World Wide Web, CGI scripts written in &perl; were a widely used method to create dynamic web pages from databases. Today, this method has been mostly replaced mostly by the `mod_perl` plugin for the &apache; web server. Among &perl;'s strengths are its built-in support for advanced regular expression expression matching and its rich archive of freely distributed modules CPAN.

&python; shines by the elegance of its class system and the ease and flexibility with which external libraries can be wrapped, in a way that they appear like standard &python; classes and functions. In contrast to &perl;, &python; has a clear and concise embedding API, which makes it the language of choice for making C and C++ programs scriptable. &php; was invented as a language directly embeddable into HTML pages and consequently has its main uses in delivering dynamic content in the web.

All these scripting languages have in common that they are widely portable between UNIX variants, &Microsoft; &Windows;, &Mac; OS or even VMS. Also, they all have implementations that are freely distributable.

### Build systems

With a compiled language, the basic tools you need are the compiler (which turns source code into object files) and the linker (which binds several object files and libraries together into one executable). When you have a large project consisting of possibly hundreds of source code files, the process of compiling may become quite laborsome. You do not want to recompile all files each time you have changed only some of them. Instead, you only want to compile those files which are affected by the changes. In general, it is not obvious which these are. When you change a function prototype in a header file, you need to compile all files which include this header file.

A tool which takes care of recompilations is `make`. It takes as input a so-called `Makefile`, which declares some targets, the commands which are to be executed to "make" the target, and a set of dependencies. We cannot go into the details here. However, we recommend that you make yourself accustomed to the syntax of `make`. Even if you normally do not use it directly, an understanding of the fundamentals of the build system can be useful. See the GNU Make Manual.

### GUI Development

Application developers become even more encumbered by having to not only create program libraries and logic, but also provide a easy to use custom built user interface that is both intuitive and functional. Most programmers receive little to no training in GUI development, and as a result user interfaces are poorly designed.

## &kdevelop; Overview

### How to obtain KDevelop

&kdevelop; can be found via the project home page at http://www.kdevelop.org or via the KDE ftp site &kdevelop; is also available from many different Linux distributions.

Anonymous CVS repository snapshots are also available. The module name is kdevelop. See the instructions on the KDE website for details on how to obtain the &kdevelop; source code.

### &kdevelop; Requirements

In order to successfully compile and use &kdevelop;, you need the following programs and libraries which are available on most platforms as distribution packages and thereby can be installed easily.

### Required:

- gcc/g++ 2.95, 3.1, 3.2 (or compatible)

- GNU make (or compatible)

- perl 5.004

- autoconf 2.54 or greater

- automake 1.6.2 or greater

- flex 2.5.4

- Qt 3.0.3 or greater

- KDE 3.0.4 or greater

### Optional:

- dot, from www.graphviz.org

### &kdevelop; Compilation and Installation

In order to compile and install &kdevelop; on your system, type the following in the base directory of the &kdevelop; distribution:

## Overview: &kdevelop;'s Features

### User Interface Modes

&kdevelop; 3.0 offers developers four separate interface modes: Multiple Document, Tabbed Document, Toplevel Window , and IDEAl.

#### Multiple Document Interface (MDI)

Screenshot

#### Tabbed Document Mode

Screenshot

#### Toplevel Window Mode

Screenshot

#### IDEAl Window Mode

Screenshot

### Plugin Parts

KDevelop 3.0 offers extensible modules, or parts, to be loaded at runtime and on demand. This allows developers to only turn on features that they need or want for their development.

Some of the parts are considered global - that is, they effect the entire operation of &kdevelop;. For example, the uimode part allows a developer to select which user interface they wish to use.

Other parts are project specfic, and are only utilized when a project of that type is loaded. The Automake Manager, for example, only needs to be active when an Automake based project is currently loaded. Otherwise, this part will not be active.

Active parts can have many effects on &kdevelop;. Depending on their function, they may add extra menus, extra menu items, extra tool buttons, etc.

Globally, a project will rely on some form of project management system. &kdevelop; offers four project management systems:

### Project Management Parts in &kdevelop;

antproject | ANT Project Manager
autoproject | Automake Project Manager
customproject | Custom Project Manager
trollproject | QMake based Project Manager

### Global Parts in &kdevelop;

Part Name | Description
appwizard | New Project Wizard
history |
konsole | Embedded Konsole
editor-chooser | Chooses an internal text editor
doctreeview | Documentation Viewer
openwith |
fileselector | A file selection widget
uimode | Customize the UI mode
texttools | Additional text tools
tipofday | A tip of the day
grepview | A graphical grep utility
cvs | CVS Support
tools |
regexptest | A regular expression tester
abbrev | Abbreviation Expansion
filter |
valgrind | A graphical valgrind frontend

### Language Support Parts in &kdevelop;

cppsupport | Support for C/C++
fortransupport | Support for Fortran
javasupport | Support for Java
perlsupport | Support for Perl
phpsupport | Support for PHP
pythonsupport | Support for Python

### Project Specific Parts in &kdevelop;

astyle |
buglist |
classview | Classview Manager
ctags |
debugger | GNU Debugger Manager
diff |
distpart |
doxygen |
fileview |
javadebugger |
manager |
nedit |
outputviews |
perforce |
qeditor |
scripting |
scriptproject |
sourcenav |
svn |
visualboyadvance |
windowmenu |

### Project Management Systems

#### Automake Project

Projects created with &kdevelop;'s Automake Project Manager make it very easy for developers to use the GNU standard development tools. In opposition to the self-creation of Makefiles, which have to be written anyway because of the project's complexity, those provide not only a better way of Makefile generation but also a good and safe way to provide a fast adaption towards different systems by autoconf-generated configure scripts.

The distribution of your applications does not require the end-user to have anything different installed other than a C++ compiler and the appropriate development libraries, which is most often the case; but ou can as well distribut binary packages of your application. In either way, the end-user of your product does not have to have &kdevelop; installed. For giving away your sources, we advise to include the project file of &kdevelop; as well, as this makes it very easy for other developerss to work with your sources if they use KDevelop as well. For projects where several developers, maybe working on different places, are involved, this should be the case anyway to ensure consistency of the Makefiles so you don't run into trouble. Especially on multi language applications, translators won't actually work with the source code, except in cases that require correction for enabling translation support.

#### QMake Project

For developers who enjoy the flexibility and feel of Qt's qmake system, &kdevelop; offers the ability to handle qmake based projects (.pro files) within the GUI.

## Getting Started: The Application Wizard

### New projects

To create a new project in &kdevelop; 3.0, select New Project from the Project menu. You should see the New Project Wizard, as seen below:

#### A screenshot of the Create New Project Wizard

Fill out the appropriate information, and select Next

### Importing existing projects

To import an existing directory in &kdevelop; 3.0, select Import Existing Directory from the Project menu. You should see the Import Directory Wizard, as seen below:

#### The Import Directory Dialog

### Converting old &kdevelop; project files

&kdevelop; 3.0 ships with a utility called `kdevprj2kdevelop`. This utility can be used to convert older &kdevelop; project files to 3.0 files.

## Editing

### Keyboard mapping

In the following, we will list the default keybindings of the default editor. You can configure them as you like (how?)

Left | Moves one character left
Right | Moves one character right
Ctrl Left | Moves one word left
Ctrl Right | Moves one word right
Up | Moves up one line
Down | Moves down one line
PgUp | Moves up one page
PgDn | Moves down one page
Ctrl PgUp | Moves to the beginning of the file
Ctrl PgDn | Moves to the end of the file
Home | Moves to the beginning of the line
End | Moves to the end of the line

For all the keys above, the Shift can be pressed additionally, to mark from the current cursor position to the one afterwards.

Backspace | Deletes one character left
Delete | Deletes the character under the cursor
Ctrl C | Copies the selected text to the clipboard
Ctrl V | Pastes the selected text from the clipboard
Ctrl X | Deletes the selected text and puts it into the clipboard
Ctrl Z | Undo
Shift Ctrl Z | Redo

### Searching and grepping

#### Searching for text

Ctrl F- Find Ctrl R- Replace

#### ISearch

The conventional search with Edit Find requires you to specify the full search term before starting. Most of the time, it is much faster to search incrementally. If you click into the edit field labeled ISearch in the toolbar, the search is performed as you type. You will find that often the desired term is already found after typing in 3 or 4 letters.

#### Grep

Both search mechanisms described above are restricted to searching within one source file. An additional tool which allows you to search through a (possibly large) number of files is available through the Search in Files... item in the Edit menu. It is basically a frontend for the &grep;(1) program.

In the dialog, you can specify which files are searched. There is a number of wildcard patterns available in a combo box. In this way, you can easily restrict the find mechanism to header files. Furthermore, you specify a directory where the search is started. If you check the Recursive box, the search iterates through all directories in the hierarchy below this one.

The search term is in general a regular expression following POSIX syntax. For example, you can use the term `"\<K.*"` if you want to find all words which begin with the letter K. The following characters are interpreted in a special way:

`.` | Matches any character
`^` | Matches the beginning of a line
`$` | Matches the end of a line
`\<` | Matches the beginning of a word
`\>` | Matches the end of a word
`?` | The preceding item matches less than once
`*` | The preceding item is matched zero or more times
`+` | The preceding item is matched once or more times
`{n}` | The preceding item is matched exactly n times
`{n,}` | The preceding item is matched n or more times
`{,n}` | The preceding item matches less than n times
`{n,m}` | The preceding item matches at least `n` times but less than `m` times

Backreferences to bracketed subexpressions are also available by the notation `\n`.

For C++ programmers, as special bonus there are some search templates available for typical patterns. These allow you to search for example all calls of member functions of a certain object.

Once you start the search by clicking on the Search button, it will be performed by an external, asynchronous process. All found items will appear in the view called Grep. You can then jump to the found items by clicking on them. Note that grep scans the files as they stored in the file system. If you have modified versions of them in your editor, you may get some mismatches in the line number, or some found items will be invalid. You can avoid this by saving all files beforehand.

### Creating new files and classes

## The file browsers

On the left side of the main window, &kdevelop; can display various kinds of lists and trees for the selection of files:

- ## File Tree

  This shows a tree view of the file hierarchy below the project directory. If you click on a file, it is loaded into the editor. For files which do not contain text, KDevelop starts an application that can handle the respective MIME type.

  The file tree is regularly updated whenever something changes in the file system. For example, if you create new files or directories (even outside &kdevelop;), this is immediately reflected in the file list. On Linux, this feature makes use of the FAM library. On other operating systems or over NFS, the directories shown are polled in small intervalls.

  The file tree hides files which are usually not interesting, like object files. In the Project options under File views, you can configure (as a comma separated list of wildcards) which patterns are used to filter out irrelevant files.

  Furthermore, you can decide to restrict the file tree to show only files which belong to the currently loaded project. This can be toggled by clicking with the right mouse button on the root item of the tree.

  ### A screenshot of the file tree

- ## File Groups

  This shows the files belonging to the project, grouped by their file name extension. As in the file tree, you can edit a file by clicking on it with the left mouse button.

  The groups shown in this view can be configured under File views in the Project options dialog. In order to customize the view to your needs, it is helpful to understand how files are distributed on the groups. For each file, &kdevelop; goes through all groups from top to bottom. In each group, it looks whether the file name matches one of the patterns. If there is a match, the file is shown in this group and the iteration is aborted. This makes it clear that more general patterns should be put below more specific ones. For example, an asterisk for the Other group should be the last pattern.

## The class browser

When working on a project in an object-oriented language, your emphasis when working on a project is not on the source files and their names, but on the classes and their relationships. In order to help you navigating in the space of defined classes and symbols, &kdevelop; includes various class browsers that visualize the class structure in different ways.

### Class view

This view is shown on the left side of the main window and contains a linear list of all classes, variables and functions in your project. It is designed as a tree view. If you open a class node by clicking on bit, a list with all methods and attributes of the respective class is shown.

#### A screenshot of the class view

The class view works in two different modes. By default, all symbols are grouped into "Classes", "Structs", "Functions", "Variables" and "Namespaces". In the context menu of the view, you can choose List by Namespaces. In this mode, the namespace hierarchy is shown and the symbols grouped into the respective namespace where they are defined. This may be more useful in projects which make heavy use of (nested) namespaces. It is less useful in projects without namespaces.

You can also change the way in which class names are displayed. Normally, the names of the classes are shown, without the namespace in which they are defined. This means, you cannot immediately distinguish classes with the same name in different namespaces. If you rest for a while with the mouse over an item, the full scoped name is shown as a tooltip though. You can decide to always display the fully scoped class name by choosing Full Identifier scopes from the context menu.

Clicking on a class or method in the class view brings you to its definition. You can also jump to the declaration of a method by choosing Go to declaration from the context menu. In the context menu for classes are also the items Add method.. and Add attribute.... This opens dialogs where you can generate new method and variable declaration in the respective class, together with an empty implementation.

### Class tools

The class tool dialog is activated by right clicking on a class in the class view and choosing Class tool....

### Class hierarchy

## The documentation browser

### A screenshot of the documentation tree

## Building and Project management

This chapter deals only with compiled projects, such as C++, Java or Fortran projects. Projects for scripting languages like Python and PHP work very differently.

In overview-buildsystems we have given a rough overview of the build systems commonly in use on UNIX systems. We now give a detailed introduction into the project management modules supported by &kdevelop; The most important one is the `autoproject` plugin which serves as a frontend to the collection of scripts sometimes referred to as GNU autotools (&automake;, &autoconf;, &libtool;). Almost all application templates use this project management.

In addition, &kdevelop; contains the `customproject` plugin, which can be used for projects for which you maintain your own `Makefiles`, but also for projects that use the tool `ant` which is very common in the Java world, or projects using `qmake`.

### Automake projects

#### Autoconf

##### Effect of the configure script

`Makefile.in` into `Makefile`

    prefix = @prefix@
    INSTALL = @INSTALL@
    build_triplet = @build@
    CXX = @CXX@

    prefix = /home/bernd/kde3
    INSTALL = /usr/bin/ginstall -c -p
    build_triplet = i686-pc-linux-gnu
    CXX = g++

`config.h.in` into `config.h`

    /* Define if you have libz */
    #undef HAVE_LIBZ
    /* The size of a `int', as computed by sizeof. */
    #undef SIZEOF_INT

    /* Define if you have libz */
    #define HAVE_LIBZ 1
    /* The size of a `int', as computed by sizeof. */
    #define SIZEOF_INT 4

#### Automake

#### KDevelop's automake manager

##### A screenshot of the Automake manager

#### Building and installing libraries

- -rpath

- PIC

- static

- plugins: no-undefined

### Custom Makefiles and build scripts

### Compiler options

### Make options

## Advanced autoproject usage

### Multiple build configurations

### Cross-compiling

When you have suitable cross compilers available, you can cross compile your programs for processors and operating systems different from the system where &kdevelop; and the compiler is running. The GNU compiler collection GCC can be configured and compiled as a cross compiler if you compile it yourself. Consult the GCC info pages for more information. Some Linux distributions also provide binary packages.

An automake based package can easily be cross-compiled by specifying the `--host` option to the configure script and setting the `CC` and `CXX` environment variables to the respective cross compiler binaries. Often you want to switch between a the cross-compiled version of your application and one compiled for your development system. For this, it is advantageous to use &kdevelop; capability of creating multiple build configurations, as explained in buildconfigurations. Once you have created a new build configuration for cross-compiling in the Project Project Options... dialog, add the option

    --host=platform

to the configure options. The `platform` name is a tuple of the form

    cpu-vendor-os

or

    cpu-vendor-kernel-os

For many combinations, you can use a short form, for instance i386-linux or arm-elf.

### Qt/Embedded

Qt/Embedded is a version of the Qt library that does not use the X window system, but draws directly to the framebuffer on Linux systems. It is therefore interesting for embedded systems which have tight restrictions on the memory usage of the whole system. Its API is fully compatible with the one of the X11 version.

Developing an application for Qt/Embedded with &kdevelop; is not very different from developing a program for the X11 version of Qt. In fact, you can use the same codebase for both versions. If you use the autoproject project management, you switch to the embedded version by passing the argument `--enable-embedded` to the configure script. You can set this in the Project Project Options... dialog under Configure Options. With the option `--with-qt-dir=DIR` you set the directory in which Qt/Embedded is installed.

After configuring and compiling your application with these options, it will link with the `libqpe.so` library. This version of your application will not normally run when you use X11. In order to test it, run it under the control of the program qvfb (Qt Virtual Frame Buffer). This is done by starting qvfb and then starting your application with

    app -qws -display QVFb:0

Naturally, when you have a working version of your application, you will want to use it on the target processor. For this, it will probably be convenient to create multiple build configurations, as explained above, so that you can quickly switch between the version running on your development system and the version running on the target system.

Applications for Qt/Embedded normally run as single applications on the device they are designed for. Trolltech also supports Qtopia, which is a collection of applications for PIM, web browsing and various other areas that work together in a consistent manner. It is the standard environment for instance on the Sharp Zaurus. You can write applications that integrate into this environment by using the Qtopia SDK. This implies making your application class a subclass of `QPEApplication` and linking to the library `libqpe.so`. If you develop your application with the autoproject project management, you have to add `--enable-qtopia` to the configure options.

## The debugger

For C and C++, &kdevelop; contains an internal debugger that is directly integrated with the editor. Technically, it is implemented as a frontend that uses the portable GNU debugger gdb through a pipe. The debugger can be started in several ways:

- With Debug Start, the main program of your project is loaded into the debugger.

- Using Debug Start (other) Examine core file you load a core file into memory, which is generated by the operating system kernel when the program has crashed (The generation of core files may be switched off on your system, see ulimit(1)). This is useful for a post-mortem analysis of a program.

- With Debug Start (other) Attach to process you invoke the debugger on an already running program. You will be shown a process list where you can select the process which the debugger should take over.

- Note that debugging is only possible if your project has been compiled with debugging information enabled. It can be activated in the Compiler options dialog. When this option is switched on, the compiler generates additional data which allows the debugger to associate file names and line numbers with addresses in the executable.

The debugger frontend offers several views "into" the process:

- ## Variables

  This window lists the values of all local variables at the current execution point of the program. It covers the variables in the complete call stack, i.e. the function where the process was interrupted, the function that called this function, and so on up to `main()` function.

  Another branch in the variables contains watch variables. You can configure yourself which variables are shown here. Both local and global variables can be watched. You can add variables either by clicking on the Add button or pressing RETURN while the Watch item is selected. They can be removed again via the context menu.

- ## Breakpoints

- ## Frame stack

- ## Disassemble

### Setting breakpoints

### Options

### Display mangled names

In C++, function names in the executable are "mangled", i.e. the function names include information about the argument types. This is necessary in order to support overloading of functions. The mangling algorithm is not standardized and differs even between different versions of the GNU C++ compiler.

In the disassembling window, normally unmangled names are displayed, so function signatures appear in the similar way as in the source code, so they are easily readable. Alternatively, you can decide to see mangled names.

### Try setting BPs on lib load

The debugger backend gdb does not allow to set breakpoints within code that is not currently loaded. In a highly modular application, where often code is only loaded on demand as a plugin (using the libc function `dlopen(3)`), this can be incovenient. Therefore, &kdevelop; rolls it own support for breakpoints in shared libraries. If you set this option, it allows you to set breakpoints in libraries which are not loaded. Then, whenever gdb notifies that a library is loaded, &kdevelop; tries to set the pending breakpoints.

### Enable floating toolbar

## Python

## PHP

## Using CVS

&CVS; is the revision control system which many open source projects - including KDE - are using. It stores all sources codes in a central place, called the repository. From the repository, developers can check out a current version of the project or snapshots of it at arbitrary points of time. In contrast to some other revision control systems, it is not necessary to lock files one wants to work on. So development can be highly parallelized.

Whenever a developer has finished a task, he commits his code (accompanied by a log message). &CVS; takes the job to merge the changes made by several developers. It can of course happen that developers work on the same piece of code, resulting in a conflicting set of changes (in practice this occurs seldom, and is often a sign of a lack of communication). In this case &CVS; rejects a commit; only after all conflicts are resolved, a file can be commited.

So far, this has been a description of the basic features of &CVS; one usually has to cope with. But &CVS; can provide a lot more: One can maintain several branches of a project (e. g. KDE 1.1.2 and KDE 2 were branches in KDE's development tree), merge changes from one branch to another, ask for differences between revisions, the revision history of files etc.

&CVS; is implemented as a client-server system. As a user, all communication with the repository goes through the command line program &cvs;. A higher level user interface is available through frontends like Cervisia () or TkCVS (). In &kdevelop;, only a small part of the &cvs; functionality which is important for your daily work can be used directly.

Basic knowledge of &CVS; usage is assumed. In particular, you should know how to checkout a given project from the repository. We recommend the book "Open Source Development With CVS" by Karl Fogel which is freely distributed (except for the non-technical chapters). See .

In the file views, the following context menu items are available:

- ## Add to Repository

  Prepares the marked file for addition to the repository. The file is transferred to the repository when you commit it (or the containing directory) the next time.

- ## Remove from Repository

  Prepares a file for removal from the repository. This also deletes the file on the local file system, so use this feature with care!

- ## Update

  Runs `cvs update` to merge any changes from other users into your working directory. When you use this menu item over a directory, the update normally happens recursively, except if you have disable this in the configuration file `.cvsrc`.

- ## Commit

  Runs `cvs commit` to upload any locally made changes to the repository. Note that you should update before doing this. Otherwise, when another user has committed his own changes before, &CVS; may give you an error message.

All these commands are invoked as subprocesses by &kdevelop; without any further command line options or environment variables. This may be a problem when the connection with the &CVS; server goes through a &ssh; connection and requires that you enter your password each time you commit or update. This is for instance necessary when your project is hosted on `sourceforge.net`. Workarounds for this problem are described on the CVS/SSH FAQ which you can find in the SourceForge documentation.

## Leveraging external programs

Although &kdevelop; is a so-called "Integrated" development environment, it will never contain all features that you may want to use, and the capabilities of its editor will never suffice to perform often-used text processing tasks. As a genuine UNIX program, &kdevelop; contains several possibilities to start external programs, plugin external programs to work on files, or use external filters to process the content of the editor.

The most general and simple feature of this kind is the tool menu, which you can freely configure. This is done in the Settings Configure KDevelop.... dialog under External tools.

Other tools will be discussed in the chapter plugintools.

## Plugin Tools

&kdevelop; contains a large number of little tools that help you to perform certain task. Most of them are realized as plugins. This means, if you do not like one of them, you can simply disable it in the Project options dialog under Plugins (for project-wide plugins) or under Settings Configure KDevelop.... Plugins which are switched off do not clutter your menus and are not loaded into memory.

- ## The abbrev plugin

  This plugin expands abbreviations into frequently used code snippets. It is activated by pressing Ctrl Space. For example, when you enter `"ife"` into a C++ in the editor and press Ctrl Space, you obtain an `if-else` code template and save some key strokes. The set of supported abbreviations depends on the programming language of the edited file. For example, for PHP you will obviously be interested in other code templates than for Java.

  The set of code templates is configurable. You can see which ones are available in the Settings Configure KDevelop... dialog under Abbreviations

- ## The filter plugin

  This offers two features. If you select Tools Execute command, you can enter a shell command. The output of this command is inserted into the editor buffer when you hit the Start button.

  A related feature is available under Tools Filter selection through command.... In order to use this, you must select a text area in the editor. If you now enter a shell command and hit the Start button, the command is started and the selection used as the standard input for it. The standard output of the command is then inserted into the editor.

- ## The doxygen plugin

  This one helps you to use the &doxygen; API documentation tool (). You can select Project Run Doxygen to generate API documentation for your current project, based on the configuration given by the file `Doxyfile` in your project directory.

  Furthermore, you can configure &doxygen; in the Project Project options... dialog. This dialog is very similar to the &doxywizard; tool.

- ## The ctags plugin

  Although the class browser gives you extensive insight into the symbols and classes of your project, you may also want to use the ctags tool. In particular, this one supports a lot more language than the class browser.

  You activate this plugin under Tools CTags.... When you start it the first time, you will be asked to generate a search database first. When you accept this, the &ctags; program will be started and will create a file named `tags` in your project directory. This is a text file containing all symbols of your source files.

  You can search in the symbol database in two ways: when the Regular expression match box is checked, the text you enter will be interpreted as a regular expression (POSIX flavor) and matched with the existing symbols. For example, the text `".*Widget"` will search for all symbols ending with `"Widget"`. If the box is not checked, the search will be verbatim.

  When searching, you will get a list of the matched symbols, accompanied with the line numbers where they are defined. You jump to the respective point by clicking on the list.

  For some languages, &ctags; distinguishes different kinds of symbols. For example, Python has classes and functions. You can selectively search only for classes by checking the respecting kinds in the dialog.

  The symbol database is normally not updated when your sources change. Consequently, after a while the line numbers will not be correct anymore and newly added classes and functions will be missing. Therefore you should update the `tags` file in regular intervals by pressing the button Regenerate.

- ## The astyle plugin

- ## The regexptest plugin

  Designing with regular expressions can be hard work. Often the first try at an expression matches too many strings. In particular, when working with a compiled language, the turnaround times when debugging a regular expression can be awkward. The regexptest plugin allows you to directly explore the changes in a regular expression. It is activated by choosing Tools Debug Regular Expression....

  In the flavor group box, you can choose the flavor of the regular expression engine used. Currently supported is the flavor defined in the POSIX standard, which is used by the &grep; program, and the extended POSIX syntax used by the program &egrep;.

  When you enter an expression, you get immediate feedback about any syntax errors in it. By entering a text under Test string, you can see whether the expression matches this string. In particular, if your regular expression includes groups, such as `"([a-z])"`, the content of the matched subgroups will be shown in a list box.

- ## The konsole plugin

## Bibliography

### GNU Make Manual

### GNU Automake

### GNU Autoconf

### Using the GNU Compiler Collection

Richard M.Stallman

### GNU Libtool

### GNU Autoconf, Automake, and Libtool

1st edition

October 2000

New Riders Publishing ISBN 1578701902

### Advanced Programming in the UNIX(R) Environment

1st edition

June 1992

W. Richard Stevens Addison-Wesley Pub Co ISBN 0201563177

### Thinking in C++, Volume 1: Introduction to Standard C++

2nd Edition

April 15, 2000

Bruce Eckel Prentice Hall ISBN 0139798099

### Open Source Development with CVS

2nd Edition

October 12, 2001

The Coriolis Group ISBN 158880173X

### Programming PHP

1st edition

March 2002

O'Reilly & Associates ISBN 1565926102

### Programming Python

2nd Edition

March 2001

Mark Lutz O'Reilly & Associates ISBN 0596000855

### Gui Programming With Python : Using the Qt Toolkit

Bk&Cd-r edition

January 2002

Boudewijn Rempt Opendocs Llc ISBN 0970033044

### Programming Perl

The Camel book

3rd Edition

July 2000

O'Reilly & Associates ISBN 0596000278

### Learning Perl

The Lama book

3rd Edition

July 15, 2001

O'Reilly & Associates ISBN 0596001320

## Further information

### Getting information

### Reporting bugs

### Licensing

&underFDL; &underGPL;

## Changes

### Changes to this document

- 2003-01-03 - Started this Changelog