# &kdevelop; User Manual

## About this manual

This user manual is intended to describe the contents and use of the &kdevelop; Integrated Development Environment (IDE) from a user's point of view. It is no programming manual nor does it describe the development process in detail. It's only aim is to guide you in the handling of the IDE.

You will here find information on the following topics:

- Development on UNIX - a historical overview on UNIX program development, the main tools necessary and why you need an IDE.

- Installing &kdevelop; - tells you where to obtain &kdevelop; and how to get it up and running.

- Overview: &kdevelop;'s features - is some kind of a warm-up, giving a short overview of what is built-in into &kdevelop; and makes you acquainted with the look and feel of this IDE.

- Configuring &kdevelop; - shows how you can taylor the IDE to suit your needs.

- Getting started: the application wizard - describes the basics on how to set up a new project in &kdevelop; using the built-in application wizard.

- Editing tools - all you need to write your source files: using the editor, searching for text both locally and project-wide, up to integrating new files and classes into the project.

- The file browsers - demonstrates various tools to look at the structure of your project and how to access the files you want to work with.

- The class browsers - describes one of the most powerful tools of &kdevelop; which lets you navigate through class dependencies and allows to easily create and access the classes and methods you need.

- Documentation - shows how to access the rich built-in documentation &kdevelop; provides and tells you how to create documentation of your project, concise and powerful API documentation providing you an overview over all your project sources as well as docbook-based user documentation.

- Building and project management - deals with the creating and management of your project, describing the basics of autoconf and automake as well as how to set up custom make files and how to use compiler or make options to taylor your application to suit your needs.

- Advanced autoproject usage - looks at ways to keep multiple build configurations, to cross-compile for diverse platforms, or to make an embedded system using the Qt/embedded library.

- The debugger interface - describes how to use the integrated gdb debugger interface so you can hunt down bugs without leaving &kdevelop; so to always maintain easy acess to the program sources in question.

- Using CVS - tells you how you can maintain your project using the CVS versioning system, a must especially if many developers work at the same project.

- Leveraging external programs - shows how to access ecternal programs and tools from within &kdevelop; thus greatly extending its capabilities.

- Plugin tools - provides you an overview on the parts which make up &kdevelop; and how you can taylor it to suit your needs by loading the necessary parts only, both IDE and project-wide.

## Development on UNIX

### Some historical remarks

From the beginning, UNIX has maintained two very different development paradigms. One is the world of system and application programming languages, where some source code is translated to machine code by a translation program, usually a compiler or an interpreter. The programming language C is an example. UNIX was the first operating system kernel to be written in such a high level language instead of tightly machine-oriented assembler which was common before that time. (In fact, the C language once even was invented to write the UNIX kernel and associated programs on a DEC PDP-11 computer.)

The other paradigm is the world of scripting languages. This world evolved with the invention of the UNIX shell which was the user's interface to the operating system - and at the same time a very high level programming language. A shell script is built from a set of small utility programs like e.g. `grep`, `sed`, or `find`. Each such utility is designed for some tightly defined job. The trick is that any such utility can be connected to another one via a simple transport mechanism, called a pipe, which directs the output of the foregoing utility into the input of the next processed one. This makes up for a very powerful and highly flexible programming tool.

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. There are numerous other programming languages, even older ones keep their place - FORTRAN77 and Ada e.g. still have their stronghold in numerical applications.

### Contemporary scripting languages

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.

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.

#### Perl

&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 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 matching and its rich archive of freely distributed modules, see: CPAN.

#### Python

&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

&php; was invented as a language directly embeddable into HTML pages and consequently has its main uses in delivering dynamic content in the web.

### The DCOP interface

Another evolution on UNIX-like scripting is the DCOP protocol. DCOP stands for Desktop COmmunikation Protocol and is implemented as a simple IPC/RPC mechanism built to operate over sockets. In effect this provides facilities similar to the traditional UNIX pipe mechanism.

Traditional shell scripting is based on fairly small tool programs which were designed to work on a strictly textual basis. DCOP allows elaborate graphical programs to communicate with each other in a quite similar way. This enables e.g. a &kde; programm to send messages to another &kde; program, or receive data from it for its own purposes.

There are drawbacks, however. To use DCOP a program must be designed to contain a special DCOP interface. And the DCOP communication process runs somewhat slowly. Yet it returns much of the power and flexibility of UNIX scripting to high-level programs which are based on a graphical user interface.

For more information, see The DCOP Desktop COmmunication Protocol library API reference of the &kde; dcop library.

### Build systems

Except in very simple cases your programming project will consist of a lot of building blocks of source code each put into a separate file for easier maintenance. To make this running you have to effectively translate all this stuff into a few machine language units in a suiting format which allows the operating system to load and execute the program.

To accomplish this, the basic tools you need are

- a text editor to write the source code files,

- a translating program, usually a compiler to turn the source code into object files,

- a librarian which collects object files into libraries to reuse them easily without the need to recompile,

- a linker which binds several object files and libraries together into one executable,

- a make system which provides some means to manage all this stuff and - not to forget

- a debugger to (hopefully) find all errors in the program and possibly some other diagnosis tools to get everything running smootly.

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 e.g. change a function prototype in a header file, you need to compile every file which includes this header file.

#### The make process

A tool which takes care of recompilations is `make`. It keeps track of all work using a set of rules which describe what to do in case some piece of information (usually a source or object code file) was changed. All rules belonging to a certain project are stored in a so-called `Makefile` which is processed by `make` any time you want to update your work.

Each rule consists of several building blocks, namely

- a target, i.e. the file to be built

- a set of dependencies, basically the names of those files the target depends on (e.g. the name of a source file, where then the target will be the name of the object file to be built) and

- the commands which are to be executed to "make" the target (i.e. to compile it or to link other object files together to build an executable progam file).

Basically the `make` command will read the rules one after another, check each file in the dependency list of a given target and make this target anew if any one of these files has changed, using the commands listed in that rule.

There are several additional possibilities to control such a make process, and a `Makefile` can thus grow very complex. We cannot go into the details here. However, we recommend that you make yourself accustomed to the syntax of `make`. Even if you do not normally use it directly, an understanding of the fundamentals of the build system can be useful. See the GNU Make Manual for more information.

For more &kdevelop; specific detail see the Building and Project Management chapter of this manual.

There are some tutorials available:

- A short autoconf tutorial written by Christopher W. Curtis available on the KDevelop home page. It concentrates on some basic steps to modify a `Makefile`.

- A more detailed tutorial can be found at . This is part of a greater set of tutorials on Developing software with GNU.

### GUI development

Application developers become even more encumbered by having to not only create program libraries and logic, but also provide an 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.

During the years some common design principles have evolved. It is strongly advised to adhere to them. This way your user interfaces will retain a common look and feel that the users of your application will gratefully appreciate.

For &kde; GUI development there is a style guide available. It is found in the &kde; User Interface Guidelines on the &kde; Developer's Corner page.

### Integrating concepts and tools: the IDE

There are separate tools available for almost any step in the programming process - planning, editing, managing files and compilation processes, debugging, documentation and the like. But once the projects grow the programming process will most likely become quite cumbersome.

Much repetitive work has to be done when designing, compiling, and debugging a program. A lot of work can be saved through the use of templates and scripts. And another lot by simple keeping the tools easily available and able to communicate with each other under a common GUI. E.g. it really does come in handy if a debugger were able to open the source file in question in an editor and place the cursor directly at the position of the bug just found.

To more easily accomplish such a scheme, Integrated Development Environments (IDE) were devised. Such an IDE integrates all templates, tools, and scripts which are needed in the development process into one single environment.

For the &kde; platform &kdevelop; is such an IDE. It provides a wide range of tools which ease program development and maintenance, even for different programming languages and across platforms.

## Installing &kdevelop;

### 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.

#### Get daily &kdevelop; snapshots from &CVS;

Anonymous &CVS; repository snapshots are available. The module name is kdevelop at `:pserver:anonymous@anoncvs.kde.org:/home/kde`.

##### Initial &CVS; checkout

To obtain an initial version of &kdevelop; you must download it (this is a so-called checkout operation) from anonymous &CVS;. Just follow these steps. (We assume you want to put your &kdevelop; copy into the `kde3src` directory.)

- `~>` `mkdir kde3src`
- `~>` `cd kde3src`
- `~/kde3src>` `cvs -z3 -d :pserver:anonymous@anoncvs.kde.org:/home/kde co kdevelop`
- `~/kde3src>` `cd kdevelop`

Now you may compile your &kdevelop; version as shown in the &kdevelop; Compilation and Installation chapter.

Note: Once you successfully checked out your &kdevelop; version, you may keep up with the changes using the update procedure shown in the next section. Please do not checkout every time you want to keep your &kdevelop; up to date!

##### Keeping your &CVS; copy actual

After you checked out (and successfully compiled) &kdevelop; from CVS as shown above, you'll want to keep it up to date in order to get all the patches. Follow these steps. (We again assume you have put your &kdevelop; copy into the `kde3src` directory.)

Note the `up` (= update) command instead of the `co` (which stands for checkout).

- `~>` `cd kde3src`
- `~/kde3src>` `cvs -z3 -d :pserver:anonymous@anoncvs.kde.org:/home/kde up kdevelop`
- `~/kde3src>` `cd kdevelop`

Note: Keep an eye on the messages &CVS; produces during the update sequence. The exact steps in the compilation sequence depend on this.

Now you can compile a new &kdevelop; version as shown in the Special &CVS; compilation considerations chapter.

### &kdevelop; requirements

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

### Required:

- gcc/g++ 2.95.3 or greater (or compatible)

- GNU make (or compatible)

- perl 5.004

- autoconf 2.52 or greater

- automake 1.6.1 or greater

- flex 2.5.4

- Qt 3.0.3 or greater

- KDE 3.0.4 or greater

### Optional:

- The ctags source navigation tool, from http://ctags.sourceforge.net, which enables you fast access to declarations and definitions by a few simple clicks on a name in the editor.

- dot, a graphics language compiler, from http:/www.graphviz.org. This tool is needed in conjunction with doxygen below if you want to have class relationships graphically displayed (which is highly recommended).

- The doxygen documentation tool, from http://www.stack.nl/~dimitri/doxygen if you want to generate concise and powerful API documentation from your projects.

- valgrind from http://developer.kde.org/~sewardj/ helps you to find memory management problems in your applications.

- Any other compiler and/or tool in case you want to develop for another language/platform than C++/&kde; or use some special facility.

Note 1: You can circumvent the need for &autoconf; >= 2.52 and &automake; >= 1.6.1. Just remove the `admin` directory in your &kdevelop; installation directory and type

`(your-kdevelop-directory)>` `ln -s $KDEDIR/share/apps/kdelibs/admin admin`

at the console. This causes &kdevelop; to use the standard settings in the &kde; `admin` directory instead.

Note 2: Be careful not to mix &qt; versions. Always link &kdevelop; to the same &qt; version your &kde; library was compiled. Otherwise you will most likely experience very strange behaviours.

### &kdevelop; compilation and installation

#### Preliminary steps

Before entering the compile sequence you must make sure all libraries and tools are available to the make system. To accomplish this some environment variables need to be properly set. The actual steps to be performed depend on the console shell you use.

Note: To avoid typing in all the statements that set the necessary environment variables every time you want to compile, you should put them in your `.bashrc` or `.cshrc` file. That way the environment variables will be properly set every time you start the shell.

##### bash shell

If you use the bash shell add the following lines:

    export KDEDIR=(where-your-kde3-is)
    export QTDIR=(where-your-qt-library-is)
    export LD_LIBRARY_PATH=$QTDIR/lib:$KDEDIR/lib:$LD_LIBRARY_PATH
    export LIBRARY_PATH=$QTDIR/lib:$KDEDIR/lib:$LIBRARY_PATH
    export PATH=$QTDIR/bin:$KDEDIR/bin:$PATH

##### tcsh shell

If you use the tcsh shell add the following lines:

    setenv KDEDIR (where-your-kde3-is)
    setenv QTDIR (where-your-qt-library-is)
    setenv LD_LIBRARY_PATH $QTDIR/lib:$KDEDIR/lib:$LD_LIBRARY_PATH
    setenv LIBRARY_PATH $QTDIR/lib:$KDEDIR/lib:$LIBRARY_PATH
    setenv PATH $QTDIR/bin:$KDEDIR/bin:$PATH

#### Compile &kdevelop;

Note: In the following discussion we assume that you have put your &kdevelop; sources in the `~/kde3src/kdevelop` directory.

##### Special &CVS; compilation considerations

In case you use a &kdevelop; snapshot from &CVS; the initial compilation steps depend on whether you just did a complete checkout or only updated the source.

##### After a CVS checkout

You should initialize the make system after a fresh checkout. The same is true every time you need to start over from scratch. (Note that you must have access to the &CVS; repository for the clean-up.) Type:

`~/kde3src/kdevelop>` `make -f admin/Makefile.common cvs-clean`

and then all of the following steps.

##### After a CVS update

The next step depends on the output of the &CVS; update sequence. If you got something like (note the U marker to the left):

    U /some_directory_path/Makefile.am

or if you just did a full checkout, you must do:

`~/kde3src/kdevelop>` `make -f Makefile.cvs`

before you proceed with all of the following steps.

##### Basic `make` command sequence

Once the basic make system is set up this way you must decide on the type of the &kdevelop; system you want to use. This is done in the following configure step which buids the actual `Makefile` the `make` command will use.

Note: You may drop the `--prefix` option in the following `configure` command lines if you want &kdevelop; be installed in the default &kde; directory. See the Some notes on `configure` options chapter for this.

##### A debug-compiled version

If you want to keep track of what your &kdevelop; application does at run-time you may buid a debug-compiled version. Just command `configure` to do so:

`~/kde3src/kdevelop>` `./configure --enable-debug=full --prefix=(where-your-kde3-is)`

##### A release-compiled version

If you only want to use &kdevelop; as-is a (smaller and faster running) release version suffices. `configure` defaults to this.

`~/kde3src/kdevelop>` `./configure --prefix=(where-your-kde3-is)`

##### Make and install &kdevelop;

`configure` will check the system and build a `Makefile` according to what it found. The `make` command will use this `Makefile` by default. Thus

`~/kde3src/kdevelop>` `make`

suffices. If necessary, now gain root user rights by

`~/kde3src/kdevelop>` `su`

and entering the root password. Then install the application:

`~/kde3src/kdevelop>` `make install`

That was all. If you installed &kdevelop; in the default &kde; directory you can now run the IDE. Otherwise some additional steps will be necessary as shown in the Non-default installation directory section below.

#### How to compile on FreeBSD

If you want compile and install &kdevelop; on a FreeBSD system follow the normal instructions but after

`~/kde3src/kdevelop>` `make -f Makefile.cvs`

do:

`~/kde3src/kdevelop>` `export CXXFLAGS="-L/usr/X11R6/lib -I/usr/local/include/db41 -I/usr/local/include -L/usr/local/lib -I/usr/X11R6/include"`

Note: You need the berkeley db 4.1 installed, if you have another version, you have to adjust the path.

##### Check the berkeley db version

To find out which berkeley db version you have installed, run:

`~>` `pkg_info | grep db41`

This should return someting like:

    db41-4.1.25_1       The Berkeley DB package, revision 4.1

##### More changes

Change the line

`ac_cv_bdb=no`

to

`ac_cv_bdb=yes`

in the `configure` file because otherwise configure can't find the db libraries.

Note: As `make -f Makefile.cvs` rebuilds the `configure` file you have to always change this entry as well.

The FreeBSD guys renamed `libdb.so` to `libdbxx.so`. So replace

`libkdevcatalog_la_LIBADD = -ldb`

by

`libkdevcatalog_la_LIBADD = -ldb41`

in `lib/catalog/Makefile.am`.

Then you can continue with the normal `configure` and `make` steps as shown above.

#### Some notes on `configure` options

##### Non-default installation directory

By default `configure` prepares the IDE to be installed in the default &kde; directory. This is necessary because &kdevelop; assumes direct access to some tools and parts which reside there. If want to use your own installation directory, you must tell `configure` this by the `--prefix` option:

`~/kde3src/kdevelop>` `./configure --prefix=(where-your-kde3-is)`

There is a caveat if you do so. You must provide a means for &kdevelop; to access the needed tools and parts in the &kde; directory. (You can still use the IDE without doing so, but with very restrained capabilities.) You have to use a shell where the following commands must be executed before you can start &kdevelop; at the shell prompt.

(Note the plural: KDEDIRS, not just KDEDIR)

- `(your-kdevelop-directory)>` `export KDEDIRS=/usr/local/kde:/opt/kde3`
- `(your-kdevelop-directory)>` `kbuildsycoca`

In a tcsh shell you must set the environment variables using:

`(your-kdevelop-directory)>` `setenv KDEDIRS /usr/local/kde:/opt/kde3`

The `kbuildsycoca` command ("build system control cache") looks around for libraries and caches their location and version, so that &kdevelop; can find them. The caveat is that it takes noticeable time - and it has to be run any time you call up the shell to start &kdevelop; from a non-default directory. You may want to put the above commands into a shell script to reduce the typing effort.

(You could as well put the lines in your `.bashrc` or `.cshrc` file, but this is not advisable as `kbuildsycoca` will then be run any time you call up the shell.)

##### Other options

(... to be written ...)

## Overview: &kdevelop;'s features

&kdevelop; integrates a lot of tools, scripts, and templates in a common user interface. Basically it consists of

- several user interface modes from which you can select the look and feel of the workspace,

- an application wizard which aids you in setting up a new project,

- several project management systems which aid in building and managing your project,

- some editing tools to easily work on your program texts

- various file browsers providing you different views on your file system,

- various class browsers to aid you in maintaining the classes and their relationships of your object-oriented programming project,

- a debugger interface to find and remove program errors from within &kdevelop;, and

- several plugin tools, extensible modules which can be loaded at runtime and on demand. This allows you to only turn on those features you really need.

- a set of other diagnosis, documentation, and optimization helper tools.

### Availabe user interface modes

&kdevelop; offers developers four separate user interface modes (click on the mode name to view an example):

- Child Frame Windows

  - All tool views are initially docked to the mainframe.

  - Editor and browser views will live like toplevel windows within a view area of the mainframe.

- Tabbed Pages

  - All tool views are initially docked to the mainframe.

  - Editor and browser views will be stacked in a tab window.

- Toplevel Windows

  - All editor, browser, and tool views will be toplevel windows directly on the desktop.

  - The main widget only contains the menu, toolbars, and statusbar.

- IDEAl

  This is a novel user interface approach optimizing both work space and intuitive handling of the tools.

  - All tool views are docked in a tabbar fashion around the mainframe area. They are grouped left, bottom, and right according to the services provided.

  - Editor and browser views will be stacked in a big sized tab window inmidst the mainframe area.

#### How to switch user interface modes

To switch the user interface mode select Settings Configure Gideon... from the menus. The Customize KDevelop dialog will pop up, where you have to select User Interface in the left hand field. This will get you to the settings page shown below.

Select a user interface mode

Select the radio button of the user interface mode you want to switch to, then press OK

Note 1: If you switch to or from the (non-windowed) IDEAl mode, you'll have to restart &kdevelop;.

Note 2: Currently there are two IDEAl modes provided - a "window" IDEAl mode and a "standard" IDEAl mode (bottom row of the radio buttons). The window mode fits with the other mdi modes, but is still experimental. You don't need to restart &kdevelop; if you select this one from one of the other three mdi modes. Yet it is recommended to use the standard IDEAl mode in everyday work for now.

#### How to maximize the work space area

To maximize space, there is a full-screen window mode available which expands the mainframe area to the screen borders. Additional space can be reclaimed by hiding the menubar. And you can of course hide any toolbar as usual in KDE applications.

#### Full screen mode

To switch to or from full screen mode select Tools Full-Screen Mode from the menus or press Ctrl Shift F . There is also a Full-Screen Mode icon in the Browse Toolbar available.

#### Hide/unhide the menubar

To hide the menu bar select Settings Show Menubar from the menus or press Ctrl M . You may also include a Show Menubar icon in a suiting toolbar, e.g. the Browse Toolbar for that purpose. To unhide the menubar you must press Ctrl M or use the Show Menubar icon if available.

### Project management systems

Globally, a project will rely on some form of project management system. &kdevelop; offers four project management systems the programmer can select from when creating a new project.

- Automake projects use the GNU standard development tools.

- QMake projects use the trolltech QMake project manager.

- ANT projects use the Apache ANT project manager for Java development.

- Custom projects require you to maintain your own `Makefiles`.

#### Automake project

Projects created with &kdevelop;'s Automake Project Manager make it very easy for developers to use the GNU standard development tools. They provide

- a better way of `Makefile` generation and

- a good and safe way for fast adaption towards different systems by autoconf-generated `configure` scripts.

#### 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.

For more information on the QMake project manager see the qmake User Guide which should be included in your distribution or have a look at the TROLLTECH Documentation home page where you may find the QMake documentation of your Qt C++ GUI Application Development Toolkit version.

#### ANT project

Java developers may want to use the Apache ANT project manager for their projects. To set up a new Ant project in &kdevelop; select Project New Project... Java Ant Project Application.

For more information see The Apache Ant Project home page.

#### Custom project

If you prefer to maintain your own `Makefiles` for your project you may use the custom project option of &kdevelop;. This may be feasible in unusually structured projects or if you want to retain full control over the `make` process.

Yet, if you do not really need the extra flexibility and control of the custom project manager you should consider Autoproject or one of the other project managers, because they considerably ease the program building and distribution processes.

#### How to distribute your application

The distribution of your applications does not require the end-user to have anything different installed other than

- an appropriate compiler,

- a linker, and

- the appropriate development libraries,

which at least for C++ applications is most often the case. But you can as well distribute binary packages of your application. In either way, the end-user of your product does not need &kdevelop; installed.

For giving away your sources, we advise to include the project file of &kdevelop; as well. This makes it very easy for other developers - if they use &kdevelop; - to work with your sources.

For projects where several developers, maybe working on different places, are involved, this should be the case anyway. So you can ensure consistency of the `Makefiles` to not 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.

## Configuring &kdevelop;

### General configuration issues

### Advanced configuration

## Getting started: the application wizard

In &kdevelop; software development work is organized in projects. Such a project keeps everything together which belongs to a complete programming task: source files, additional data files, any actually needed management facilities as the make system as well as access to all components and/or tools specially needed to get the application up and running.

Organizing all development work in projects allows you to easily switch between the global tasks at hand. This is quite handy if you e.g. work on several applications at the same time as is often the case. Tell &kdevelop; to open the project you want to work at and you may proceed in the environment just where you left.

### New projects

Whenever you want to initiate a new programming project quite a lot of formal setup procedures need to be done. An initial directory structure has to be set up, initial header and source files must be provided, the make system has to be initialized, etc.

&kdevelop; provides an easy way to initiate a new programming project - the application wizard. You will find the application wizard at menu entry Project New Project.

Only a short series of steps is necessary to start a new programming project, using the application wizard:

1. Select the programming language you want to use and the type of the application you want to build from a set of predefined templates.

2. Supply some general information as application name, directory where the application shall be built, etc.

3. Decide whether you want to use a version control system, like e.g. CVS, and supply the necessary data if needed.

4. Set up some templates for initial header and source files (if applicable).

5. Finally tell application wizard to set up all initial directory structure, starting header/source file templates, and managment tools, like e.g. an initial make skeleton, etc.

Voilà - that's all. Application wizard will have provided you with a primary functional set of programming files, where you can readily start working.

Let's look at all this in more detail now ...

#### Initial steps

To create a new project in &kdevelop;, select New Project from the Project menu. The Create New Project dialog will pop up showing an initial General page:

As you see, this dialog is divided into an upper and a lower part. In the upper part you can decide on the programming languange and application type, the lower part holds some general information.

##### Select programming language and application type

The left hand side of the upper part in this dialog is where you do the selection work. When it shows up, you'll find there a list of folders each labeled with a programming language, as for instance:

- Ada

- C

- C++

- Fortran

- Java

- PHP

- Pascal

- Perl

- Python

- Ruby

- Shell

To be precise, these folders do not contain real programming tools actually. They do lead to pre-defined templates you can use as a starting point for development in that language. To get an idea of what is provided, just open the folders one after the other. There will be a series of subfolders on some, one or more simple entries only on others. The subfolders you see organize the available templates according to some tasks, the simple entries name the templates you may select.

We cannot go into detail here on which tasks each template provides, but it's easy to find out. Whenever you select a template entry some information is displayed in the fields to the right. In the lower field you will find a short description on what the template is supposed to do. In the field above that a picture will be shown, if available, about the the outcome of the application this template produces if you compile and run it unmodified. Usually this is a screenshot of the main window the application will display.

Select the template which best fits your application's goals as a starting point. Then enter the general properties information in the lower field as shown in the next chapter.

##### Provide general information

The lower part of the Create New Project dialog General page is a framed field labeled Properties. You must provide some general information about your project here so that the application wizard knows how to build the initial structure.

##### Application Name

Your application needs a name of course. Enter this in the uppermost Properties field, called Application Name.

When you do so, you will notice that the application wizard refuses to accept special characters of any kind. The only characters accepted are:

- upper and lower case characters

- numbers

- the underline character

One prominent cause of this restriction is that the application manager will use this application name as the basis of some class names it will construct when it sets up an initial project. Thus the name of the application must stick to the rules of the programming language you use.

##### The project directory

The other prominent cause of this restriction you can see at the bottom line of the Properties area. It is labeled Final location and shows the directory where the application manager will create the application.

As you type the application name you will notice that the application wizard repeats your input at the end of the Final location line, using lower case only characters.

Thus you must select the name of your new application with care. If you end up with an already used directory the application manager will complain, albeit only at the very end of the setup process:

Once you pressed OK on this the application manager will send you back to this first General page of the Create New Project dialog, requiring you to correct the application directory.

##### The starting path

There are two ways to select another path for your new application. One is to select another name. Yet, this is not always feasible (you might e.g. set up for another version of an already existing application). As an alternative you may select another path to the application directory.

This is done in the second row input field of the Properties, named Location. What you enter here is the starting path of the new application development directory. The application manager appends the application name to this path when it initializes the new project. The result is shown in the Final location line to give you better control on what is going on.

Application manager will copy an initial value to the Location field on start-up. This is taken from what you have chosen in the Default projects directory field during the general configuration steps.

Alter the Location field contents so that the application deveopment directory shown in the Final location line will be unique.

Note: Take care that the path you enter in the Location field already exists. Otherwise the application manger will not allow you to continue to the next step, keeping the Next > button deactivated (greyed).

The application manager will warn you about non-existing paths by appending (invalid) to the Final location line. Thus, if the Next > button will remain greyed whatever you do - check here whether your application development path is valid.

##### Personal information

The fields following this are not so critical. Just supply your name (i.e. the name of the person who is responsible for the application) in the Author field, and a valid e-mail address in the Email field, so that users can give you feedback on the application.

Note 1: The application manager will integrate this information into the starting program templates if applicable. In KDE C++ programs for instance you will find it near the beginning of the `main.cpp` source file.

Note 2: Of all fields, the Email is optional, reflecting the fact that not every developer may have access to the internet. You may keep this field empty if you wish and proceed nevertheless.

##### Version and license info

Finally enter a starting version number for your new application in the Version field, and select the license under which you want your application be put from the License control.

Note: Both version and license information will as well be integrated into the starting templates in a suiting format the application type you selected does provide.

Once you have correctly entered all this information stuff, press the Next > button to proceed as will be shown in the following chapters.

#### Supply version system information

#### Supply header/source templates

#### Build the initial project files

### Importing existing projects

To import an existing directory in &kdevelop; 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; allows you to open old KDevelop 2.x project files and convert them to &kdevelop; files. To do so go to Open Project... and select KDevelop 2 project files in the Filter:. Then select project file you want to open. The project gets converted to &kdevelop; and saved as a &kdevelop; project file.

## Editing tools

### 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 browsers

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 it, 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

## Documentation

Documention unfortunately belongs to the most-overlooked programming issues. Yet, once properly set up and maintained internal and external documentation provides most valuable help.

Documentation has multiple facets. There is

- project internal documentation, mainly consisting of

  - comments in header/source files

  - internal API documentation of your project generated from the program file by special tools, e.g. Doxygen

- project external documentation, comprising among others

  - external API documentation of e.g. common system libraries (KDE, Qt, etc.)

  - any other documentation (programming language manuals, general system information, HowTo articles and the like)

All this documentation should be easily maintainable and ready at hand whenever you need it. &kdevelop; has provisions for just this.

### 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 unixdev-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

&qte; 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 &qte; 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 &qte; 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 &qte; 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 interface

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 its 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

## 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 disabled 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

### Overview

&kdevelop; 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.

### Project management parts in &kdevelop;

antproject | ANT Project Manager (Java applications)
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 |

## &kdevelop; user interface mode examples

### Child frame windows mode

Click here to return to the modes overview.

Screenshot

&kdevelop; child frame windows mode

Click here to return to the modes overview.

### Tabbed pages mode

Click here to return to the modes overview.

Screenshot

&kdevelop; tabbed pages mode

Click here to return to the modes overview.

### Toplevel windows mode

Click here to return to the modes overview.

Screenshot

&kdevelop; toplevel windows mode

Click here to return to the modes overview.

### IDEAl mode

Click here to return to the modes overview.

Screenshot

&kdevelop; IDEAl mode

Click here to return to the modes overview.

## Further information

### Getting information

### Reporting bugs

### Licensing

&underFDL; &underGPL;

## Changes

### Changes to this document

- 2003-01-03 - Started this Changelog

## 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