# Manuale Utente di &kdevelop;

2004-02-17
&kdevrelease;
Bernd
Gehrmann

    bernd@kdevelop.org

Caleb
Tennis

    caleb@aei-tech.com

Bernd
Pol

    bernd.pol@online.de

2002
Bernd Gehrmann
2002
Caleb Tennis
2004
Bernd Pol
&FDLNotice;

&kdevelop; is an Integrated Development Environment to be used for a wide variety of programming tasks.

KDE
KDevelop
IDE
sviluppo
programmazione

## Informazioni su questo manuale

This user manual is intended to describe the contents and use of the &kdevelop; &kdevrelease; 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.

Si troveranno informazioni sui seguenti argomenti:

- In a nutshell—a quick reference of the most used commands and actions.

- Development on UNIX—a historical survey of 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.

- Survey of the Features of &kdevelop;—is some kind of a warm-up, giving a short overall view of what is built-in into &kdevelop; and makes you acquainted with the look and feel of this IDE.

- Menus and Toolbars Survey—(in the appendix) provides you with a short overall view of the menu and toolbar selections available.

- Shortcut Keys—(in the appendix) lists the key sequences you may use to quickly access some specific &kdevelop; operation.

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

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

- Advanced Project Management—shows how to load existing projects, convert projects from older &kdevelop; versions, and import other existing projects. Furthermore the configuration of a project's options to suit your needs is discussed.

- 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 overall view of 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 Project Management—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;.

- 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 external programs and tools from within &kdevelop; thus greatly extending its capabilities.

- Plugin tools—provides you a survey of 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.

## In poche parole

Le informazioni di questo capitolo sono intese come un veloce riferimento per iniziare e sono utili se si dimenticano (momentaneamente) alcuni concetti di base. Se si desiderano ulteriori informazioni su un argomento, seguire il collegamento relativo.

### Look and Feel

- ### Full Screen Mode

  Select View Full-Screen Mode from the menus or press Ctrl Shift F .

- ### Hide/Unhide the Menubar

  To hide the menubar select Settings Show Menubar from the menus or press Ctrl M . To redisplay the menubar only Ctrl M is available.

### Progetti

- ### Creare un nuovo progetto

  Attraverso Progetto Nuovo progetto... verrà avviata la procedura guidata per le applicazioni.

- ### Usare inizialmente le opzioni di progetto

  Whenever you start a new project do not forget to set the Project Project Options... to your needs.

### Compilation

- ### Missing detail in compilation messages

  If during compilations you miss some valuable information in the Messages Output View window, you may have selected a too low level of messages detail. Right click in the window and select another detail level from the menu which will pop up.

### Gestore Automake

- ### Creare nuovi file in un progetto

  Selezionare il sottoprogetto nella metà superiore del Gestore Automake, poi cliccare con il tasto destro nella metà inferiore sul nome del gruppo nel quale si vuole aggiungere il file e selezionare Crea nuovo file...

- ### Aggiungere file esistenti ad un progetto

  Selezionare il sottoprogetto nella metà superiore del Gestore Automake, poi cliccare con il tasto destro nella metà inferiore sul nome del gruppo nel quale si vuole aggiungere il file e selezionare Aggiungi file esistenti...

- ### Rimuovere un file da un progetto

  Selezionare il sottoprogetto nella metà superiore del Gestore Automake, poi nella metà inferiore aprire la lista dove si vuole rimuovere il file, cliccare con il tasto destro sul file nella lista e selezionare Rimuovi.

### Problemi di compilazione/Make

- ### Errore Wrong `autoconf` version ecc.

  Ci sono diversi messaggi di errore attinenti a versioni troppo vecchie di autoconf ecc. che impediscono a `configure` di funzionare correttamente. Avviare `autoreconf` nell'albero di directory dove risiedono i relativi file `configure.in`. Questo comando tenterà di aggiornare le informazioni nei file del &GNU; Build System. Vedere `man autoreconf` per ulteriori informazioni.

## Sviluppo su UNIX

### Alcune note storiche

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

### Linguaggi di scripting contemporanei

Nell'area dello scripting, c'è stato un allontanamento dalla shell, che soffriva di problemi di portabilità, verso linguaggi che unificavano tutte le funzionalità necessarie nelle proprie librerie standard, mentre quando era necessario potevano comunque interfacciarsi verso l'esterno attraverso le pipe.

Tutti questi linguaggi di scripting avevano in comune il fatto che erano ampiamente portabili attraverso le varianti UNIX, &Microsoft; &Windows;, &Mac; OS e anche VMS. Inoltre tutti disponevano di implementazioni che erano liberamente distribuibili.

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

For more information see the Comprehensive Perl Archive Network (CPAN) website.

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

### Higher-level Scripting

Higher-level UNIX applications usually miss the speed and flexibility of the traditional character-oriented shell scripting mechanisms. This is especially true in the world of graphical user interfaces (GUI) as e.g. &kde;.

There have been attempts to provide similar mechanisms which will work on a higher application level, most notably CORBA and, in the &kde; environment, DCOP.

#### The CORBA Protocol

CORBA (Common Object Request Broker Architecture) is an attempt to let computer applications work together over networks. It was devised by the private, vendor independent OMG (Object Management Group) standards comittee.

CORBA-based programs use the IIOP standard protocol to communicate. Implementations based on IIOP are available on a wide variety of operating systems, programming languages, and networks and are thus highly portable.

The main drawback of CORBA is its rather low speed. While this may be tolerable in networks, it is a real hindrance for inter-application communications in a non-networked environment such as &kde; running on a single computer.

#### L'interfaccia DCOP

Another evolution on UNIX-like scripting is the DCOP protocol which was devised for communication between &kde; applications to overcome the limitations of CORBA.

DCOP stands for Desktop Communication 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.

Lo scripting shell tradizionale è basato completamente su piccoli programmi che sono progettati per lavorare su basi strettamente testuali. DCOP permette a programmi grafici complicati di comunicare con altri con un sistema simile. Questo permette ad esempio ad un programma &kde; di inviare messaggi ad un altro programma &kde;, oppure ricevere dati da esso per i propri scopi.

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 (although a lot faster than CORBA). But 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 COmmunications Protocol paper or The DCOP Desktop Communication Protocol library API reference of the &kde; dcop library.

### Sistemi di compilazione

Except in very simple cases a 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 one has 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 needed are

- un editor di testi per scrivere i file sorgente,

- un programma di traduzione, normalmente un compilatore, per convertire il codice sorgente in file oggetto,

- un librarian che raccoglie i file oggetto in librerie per poterli riusare facilmente senza la necessità di ricompilare,

- un linker che riunisce vari file oggetto e librerie in un eseguibile,

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

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 always easily obvious which of the files have to be recompiled.

When you e.g. change a function prototype in a header file, you need to compile every file which includes this header file. If your project contains many such files you may easily miss one or two of them if you have to do the job manually. Thus some means of automization is necessary.

#### Il processo make

Uno strumento che si occupa della ricompilazione è `make`. Esso mantiene la traccia di tutto il lavoro usando un insieme di regole che descrivono cosa fare nel caso vengano cambiate alcune parti di informazione (normalmente un file sorgente o oggetto). Tutte le regole che appartengono a un certo progetto sono conservate in un file chiamato `Makefile` che è analizzato da `make` ogni volta che si vuole aggiornare il proprio lavoro.

Ogni regola consiste di diversi blocchi, chiamati

- un target, cioè il file che deve essere compilato

- un insieme di dipendenze, fondamentalmente il nome dei file dai quali dipende il target (ad esempio il nome di un file sorgente, dove il target sia il nome del file oggetto che deve essere costruito) e

- i comandi che devono essere eseguiti per costruire il target (es. compilarlo o collegare vari file oggetto per costruire un file eseguibile).

Sostanzialmente il comando `make` leggerà le regole una per una, controllando ogni file nella lista delle dipendenze di un determinato target e, se qualcuno di questi file viene cambiato, ricreando nuovamente questo target usando i comandi elencati nella regola.

Poiché ci sono ulteriori possibilità per controllare un tale processo, un `Makefile` può diventare molto complicato. Non si scenderà ora nei dettagli, ma si raccomanda di abituarsi ad usare la sintassi di `make`. Anche se non si usa direttamente make, può essere utile una comprensione dei fondamenti del sistema di compilazione. Vedere il Manuale GNU Make per maggiori informazioni.

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

Esistono diversi tutorial disponibili, vedere i riferimenti nel capitolo riguardante la compilazione e la gestione dei progetti.

### Sviluppo di GUI

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

Attraverso gli anni si sono evoluti alcuni principi di progettazione comuni. È caldamente raccomandata l'adesione ad uno di questi, in modo che le proprie interfacce utente mantengano un aspetto comune apprezzabile dagli utenti che le utilizzeranno.

Per lo sviluppo di GUI di &kde; è disponibile una guida di stile che si può trovare nella &kde; User Interface Guidelines nella pagina Developer's Corner di &kde;.

A short introduction to common GUI design principles can be found here.

### Integrare concetti e strumenti – l'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 processes will most likely become quite cumbersome.

Much repetitive work has to be done when designing, compiling, and debugging a program. A lot of such work can be saved through the use of templates and scripts. And another lot by keeping these tools easily available and able to communicate with each other under a common GUI.

For example—would it not be convenient if a debugger were able to open the source file in question in an editor and place the cursor directly at the position of that bug just found?

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

Per la piattaforma &kde; uno di questi IDE è &kdevelop;. Esso fornisce un vasta gamma di strumenti che semplficano lo sviluppo di programmi e la manutenzione anche per linguaggi di programmazione diversi e varie piattaforme.

#### Basic Features of &kdevelop; &kdevrelease;

- Manages all development tools needed for C++ programming, such as compiler, linker, debugger and build system.

- Provides an &appwizard; which generates complete, ready-to-go sample applications.

- Allows the user to select an integrated editor based on the &kde; programmer's editor KWrite, Trolltec's QEditor, or others.

- A class generator, for creating new classes and integrating them into the current project.

- File management for sources, headers, documentation etc. to be included in the project.

- Assistance in creating application user manuals written with KDE tools.

- Automatic HTML-based API-documentation for a project's classes with cross-references to the used libraries.

- Internationalization support, allowing translators to add their target language to a project easily, including support of KBabel.

- Support for managing a project via one of several versioning systems (e.g. CVS) by providing an easy-to-use frontend for the most needed functions.

- An integrated debugger frontend.

- An integrated shell console emulator.

- Syntax highlighting in source texts.

- An auto-code completion facility for class variables, class methods, function arguments and more.

- Templates for creating various projects (KControl modules, Kicker (panel) applets, KIOSlaves, Konqueror plugins and desktop styles).

- Four navigation tree views for easily switching between source files, header files, classes and documentation, obviating the need for an external file manager.

- Cross-compiling support, with the ability to specify different compilers, compiler flags, target architecture, etc.

- Support for Qt/Embedded projects (such as the Zaurus and iPAQ).

- Inclusion of any other program you need for development by adding it to the Tools menu according to your individual needs.

## Installare &kdevelop;

In this chapter we will discuss the steps necessary to compile and install the &kdevelop; IDE:

- How to obtain &kdevelop; mainly concentrates on downloading the most recent &kdevelop; sources from CVS.

- I requisiti di &kdevelop; comprendono i programmi e le librerie che devono essere installate per compilare con successo l'IDE.

- &kdevelop; compilation and installation leads you trough all steps of compilation and installing the application.

- Come ottenere la documentazione delle API di &kdevelop; indica cosa è un'API e come ottenere un tale strumento per anvigare attraverso i sorgenti di &kdevelop;.

### Come ottenere &kdevelop;

&kdevelop; è disponibile in formato binario in molte distribuzioni &Linux; come SuSE, RedHat e altre. Questi binari sono impacchettati in formati comodi da installare, principalmente RPM. Per installarli seguire le istruzioni standard fornite con la propria distribuzione.

Si può anche ottenere i sorgenti di &kdevelop;, compilarli ed installarli personalmente. Questi sorgenti posso essere trovati attraverso la home page del progetto http://www.kdevelop.org o attraverso il sito ftp di &kde;.

#### Scaricare gli snapshot giornalieri di &kdevelop; dal &CVS;

Se si vuole rimanere sempre aggiornati con lo sviluppo corrente,sono disponibili gli snapshot attraverso il repository anonymous &CVS;. Il nome del modulo è kdevelop in `:pserver:anonymous@anoncvs.kde.org:/home/kde`.

##### Controllo iniziale del &CVS;

To obtain an initial version of &kdevelop; you must download it from anonymous &CVS;. For this so-called checkout operation follow these steps.

We assume you want to put your &kdevelop; copy into the `kde3src` subdirectory of your home directory (`~`).

- # Create the destination directory, if necessary:
- ~> `mkdir kde3src`
- ~> `cd kde3src`
- ~/kde3src> `cvs -z3 -d :pserver:anonymous@anoncvs.kde.org:/home/kde co kdevelop`
- ~/kde3src> `cd kdevelop`

Once you have successfully checked out your &kdevelop; version, you may keep up with the changes using the update procedure shown in the next section.

Keep the server load low. Please do not checkout every time you want to keep your &kdevelop; up to date! Use CVS update for this purpose.

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

##### Mantenere la propria copia &CVS; aggiornata

Dopo aver fatto il checkout (e compilato con successo) &kdevelop; da CVS come mostrato prima, si vorrà mantenerlo aggiornato in modo da avere tutte le patch. Seguire queste fasi. (Anche in questo caso si presume che si abbia la propria copia di &kdevelop; nella directory `kde3src`).

Notare il comando `up` (= update) al posto del comando `co` (che indica checkout).

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

Tenere sotto controllo i messaggi che sono prodotti da &CVS; durante la sequenza di aggiornamento. Da essi dipende l'esatta sequenza di compilazione.

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

### Requisiti di &kdevelop;

Sono necessari i seguenti programmi e librerie per compilare con successo e usare &kdevelop;. Questi sono disponibili nella maggior parte delle piattaforme come pacchetti di distribuzioni e quindi possono essere installati facilmente.

#### Requisiti:

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

  Available from gcc.gnu.org

- &gnu; make (o compatibile)

  Available from www.gnu.org/software/make

- &perl; 5.004

  Available from www.perl.com

- autoconf ≥ 2.52

  Available from www.gnu.org/software/autoconf

- automake ≥ 1.6

  Available from www.gnu.org/software/automake

- flex 2.5.4

  Available from www.gnu.org/software/flex

- Qt ≥ 3.0.3

  Available from www.trolltech.com/products/qt

- KDE ≥ 3.0.2

  Available from www.kde.org

#### Opzionali:

- 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.doxygen.org 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.

- CVS from http://www.cvshome.org if you want to use the &CVS; versioning system.

- Qualunque altro compilatore e/o strumento nel caso si voglia sviluppare in un altro linguaggio/piattaforma diverso da C++/&kde; oppure usare qualche funzione speciale.

1. You can to a certain extent circumvent the need for &autoconf; ≥ 2.52 and &automake; ≥ 1.6. Just remove the `admin` directory in your &kdevelop; installation directory and type

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

   alla console. Questo farà sì che &kdevelop; usi le impostazioni standard nella directory `admin` di &kde;.

2. Si presti attenzione a non mescolare versioni diverse di &qt; . Collegare sempre &kdevelop; alla stessa versione delle librerie &qt; con cui sono state compilate le librerie &kde;. Altrimenti probabilmente si otterranno comportamenti anomali.

### Compilazione e installazione di &kdevelop;

Once all requirements are met, you are ready to compile and install &kdevelop;. This chapter will discuss the necessary steps to do so.

- Preliminary Steps tells you about setting up a proper environment.

- Compile &kdevelop; deals with obtaining the &kdevelop; sources from &cvs;, how to prepare them for the installation process, and finally shows the steps necessary to compile and install &kdevelop;.

- How to Compile on FreeBSD discusses special considerations about the Berkeley Database systems in order to compile and install &kdevelop;.

- Some Notes on configure Options tells you how to run &kdevelop; if it has been installed in another location than the &kde; directory.

#### Fasi preliminari

Prima di addentrarsi nella sequenza di compilazione è necessario assicurarsi che siano disponibili tutte le librerie e gli strumenti per il sistema di make. Per realizzarlo è necessario che alcune variabili d'ambiente siano impostate correttamente. Le fasi da compiere dipendono da quale shell si usa.

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

##### Setting the Environment for the bash Shell

Se si usa la shell bash aggiungere le linee seguenti:

- `export KDEDIR=`(path to your KDE installation)
- `export QTDIR=`(path to your Qt library)
- `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`

##### Setting the Environment for the tcsh Shell

Se si usa la shell tcsh aggiungere le linee seguenti:

- `setenv KDEDIR` (path to your KDE installation)
- `setenv QTDIR` (path to your Qt library)
- `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`

#### Compilare &kdevelop;

Si presume che in seguito la propria copia dei sorgenti di &kdevelop; sarà messa nella directory `~/kde3src/kdevelop`.

##### Considerazioni speciali per la compilazione &CVS;

Nel caso si usi uno snapshot da &CVS;, le fasi iniziali della compilazione dipendono dal fatto che si sia eseguito di un checkout completo oppure un aggiornamento dei soli sorgenti.

###### Dopo un checkout CVS

You must initialize the make system after a fresh checkout. The same is true every time you need to start over from scratch. Type:

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

and then all of the following steps.

You might need access to the &CVS; repository for the clean-up if any corrupted or missing files must be reconstructed.

The `cvs-clean` command will remove every file not in &CVS; from the directory! Make sure to back up any valuable information before you issue this clean-up command.

###### Dopo un aggiornamento CVS

The next step depends on the output of the &CVS; update sequence. If you got something like (there may be a U or a P marker in the leftmost column, both denoting the file has been changed):

    U /some_directory_path/Makefile.am

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

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

before you proceed with all of the following steps.

##### Sequenza dei principali comandi `make`

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

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.

###### Versione compilata con il supporto per il debug

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

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

###### Una versione compilata release

Se si desidera solo usare &kdevelop; così com'è sarà sufficiente una versione release (più piccola e più veloce). È la versione di default di `configure`.

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

Se si vuole compilare la propria documentazione API per &kdevelop;, si deve includere anche un'altra opzione nel comando `configure`:

- ~/kde3src/kdevelop> `./configure --`(options-as-above) `\`
- `--with-kdelibsdoxy-dir=$KDEDIR/share/doc/HTML/en/kdelibs-apidocs`

###### Compilare e installare &kdevelop;

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

- ~/kde3src/kdevelop> `make`

suffices. If necessary, now gain root user rights using the command

- ~/kde3src/kdevelop> `su`

e inserire la password di root. Quindi installare l'applicazione:

- ~/kde3src/kdevelop> `make install`

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

#### Come compilare su FreeBSD

Se si vuole compilare e installare &kdevelop; su un sistema FreeBSD si devono seguire le normali istruzioni dopo aver inserito i seguenti comandi

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

you must make the Berkeley specific include files and libraries available to the compiler. This is done through the `CXXFLAGS` environment variable:

- ~/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"`

You need the berkeley db 4.1 database version installed, if you have another version, you must adjust the path.

##### Check the Berkeley Database Version

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

- ~> `pkg_info | grep db41`

This should return something like:

    db41-4.1.25_1       The Berkeley DB package, revision 4.1

##### Ulteriori cambiamenti

Cambiare la linea

`ac_cv_bdb=no`

in

`ac_cv_bdb=yes`

nel file `configure`, altrimenti configure non potrà trovare le librerie db.

As `make -f Makefile.cvs` rebuilds the `configure` file you have to change this `ac_cv_bdb` entry every time after you issued this command.

As the FreeBSD guys renamed `libdb.so` to `libdbxx.so` you must replace

`libkdevcatalog_la_LIBADD = -ldb`

con

`libkdevcatalog_la_LIBADD = -ldb41`

in the `lib/catalog/Makefile.am` file.

Now continue with the usual `configure` and `make` steps as shown above.

#### Alcune note sulle opzioni di `configure`

##### Directory di installazione non di default

Per default `configure` predispone l'installazione dell'IDE nella directory di default di &kde;. Questo è necessario perché &kdevelop; accede direttamente ad alcuni strumenti e componenti che risiedono lì. Se si vuole usare una propria directory di installazione, lo si deve indicare a `configure` attraverso l'opzione `--prefix`:

- ~/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 when running. (You can still use the IDE without doing so, but with very restrained capabilities.)

Call up a shell and have the following commands executed before you start &kdevelop; at the shell prompt.

Take care to use the plural: It is `KDEDIRS`, not just `KDEDIR`)

- ~> `export KDEDIRS=/usr/local/kde:/opt/kde3`
- ~> `kbuildsycoca`
- (Now start &kdevelop;:)
- ~> `kdevelop`

- The `KDEDIRS` environment variable must be set to the list of active &kde; directories in your system. We use
- `/usr/local/kde`:`/opt/kde3`
- as an example only.
- The `/usr/local/kde` directory may for instance contain an incomplete &kde; version you compiled for debug purposes, and the `/opt/kde3` directory may in addition contain the standard &kde; version from your distribution that is used for everyday work.

Nella shell tcsh si deve impostare la variabile d'ambiente così:

- ~> `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.

(Si potrebbero anche mettere i comandi nel proprio file `.bashrc` o `.cshrc`, ma non è consigliabile poiché`kbuildsycoca` verrebbe eseguito ogni volta che si chiama la shell).

The `kbuildsycoca` command does not run from within the root. You must call it from a non-root user. (But is not a very good idea after all to do software development from within the root!)

### Come ottenere la documentazione API di &kdevelop;

API is the short form of Application Program Interface. Actually such an API cotains a series of descriptions (i.e. calling conventions) by which an application program can access the operating system and other services. In our context, however, a broader definition was adopted. The API of a &kde; or &Qt; application is an abstract of the classes and methods interfaces, a synopsis to be used like a dictionary to navigate the sources.

There is a version of the most current API available at the KDevelop-Home website. It will be automatically updated every 24 hours so you can keep up.

Alas, this version is best used read-only over the internet. If you do not allways have net access you may as well build your own API documentation from the &kdevelop; sources. To do so, you must tell the automake system where to find the KDELIBS API in your system. This is accomplished by the special option `--with-kdelibsdoxy-dir` in the `configure` command when you prepare to compile the &kdevelop; sources:

- ~/kde3src/kdevelop> `./configure --`(options-as-usual)`\`
- `--with-kdelibsdoxy-dir=$KDEDIR/share/doc/HTML/en/kdelibs-apidocs`

(`make` will replace the global `$KDEDIR` variable with the actual &kde; directory setting recorded therein.) Then issue a `make` command as usual. After the &kdevelop; IDE has been built you have the option to build the API as well. For this you must issue

- ~/kde3src/kdevelop> `make apidocs`

This will build a `Doxyfile` in your &kdevelop; base directory which in turn will be processed by the Doxygen application to build quite a lot of `.html` API files. When this rather lengthy API building process (may last more than an hour on a slow system) finally comes to an end, you must install the API just like you have to install the &kdevelop; IDE itself. If necessary obtain superuser rights by

- ~/kde3src/kdevelop> `su`

e inserire la password di root. Quindi installare i file API:

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

Una volta fatto, `make` comunicherà la directory dove alla fine si potranno vedere i contenuti della documentazione delle API. Annotando l'indirizzo lo si potrà usare sia con &konqueror; che all'interno di &kdevelop;, nel caso si siano impostati i sorgenti come un progetto su cui lavorare.

You will most probably see a lot of warning and/or error messages during the API build run by Doxygen. Best ignore them, they are of interest to the &kdevelop; developers only. If the API generation ever comes to a successful end, the `.html` API files will be useable.

## Survey of &kdevelop; Features

&kdevelop; integra in una interfaccia utente comune molti strumenti, script e modelli. Fondamentalmente essa consiste di:

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

- la procedura guidata per le applicazioni che aiuta nella creazione di un nuovo progetto,

- diversi sistemi di gestione dei progetti che aiutano nella costruzione e gestione del progetto,

- alcuni strumenti di editing per lavorare con facilità sul testo dei propri programmi

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

- un'interfaccia per il debug per trovare e rimuovere gli errori dei programmi dall'interno di &kdevelop;, e

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

- un insieme di altri strumenti di diagnosi, documentazione e aiuti nell'ottimizzazione.

### Modalità dell'interfaccia utente disponibili

&kdevelop; offre agli sviluppatori quattro modalità diverse dell'interfaccia utente (cliccare sul nome della modalità per vedere un esempio):

- IDEAl

  Questo è un nuovo approccio all'interfaccia utente che ottimizza sia l'area di lavoro che la manipolazione intuitiva degli strumenti.

  - Tutti gli strumenti vista sono ancorati attorno all'area della finestra principalecon delle etichette. Sono raggruppati a sinistra, destra, in alto e in basso a seconda dei servizi che forniscono.

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

- Finestre Childframe

  - Tutti gli strumenti di vista sono inizialmente all'interno della finestra principale.

  - Le viste dell'editor e del browser saranno come finestre principali all'interno dell'area della finestra del programma.

- Pagine etichettate

  - Tutti gli strumenti di vista sono inizialmente all'interno della finestra principale.

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

- Finestre Toplevel

  - Tutti gli editor, il browser e gli strumenti di vista saranno finestre principali direttamente sul desktop.

  - Il widget principale contiene soltanto il menu, le barre degli strumenti e la barra di stato.

#### Come cambiare le interfacce utente

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

Selezionare una modalità dell'interfaccia utente

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

#### Come massimizzare l'area di lavoro

Per massimizzare lo spazio, è disponibile una modalità schermo intero che espande l'area della finestra principale fino ai bordi dello schermo. Ulteriore spazio può essere recuperato nascondendo la barra dei menu. Si possono anche nascondere tutte le barre degli strumenti come nelle applicazioni KDE.

##### Full Screen Mode

Per attivare o disattivare la modalità schermo intero selezionare Visualizza Modalità schermo intero dai menu oppure premere Ctrl Shift F . È disponibile anche una icona nella barra di navigazione.

##### Hide/Unhide the Menubar

To hide the menubar 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.

### Elementi dell'interfaccia utente

(... to be written ...)

#### The Workarea

(... to be written ...)

#### The &kdevelop; Titlebar

(... to be written ...)

#### The &kdevelop; Statusbar

(... to be written ...)

#### The menubar

(... to be written ...)

#### The Toolbars

(... to be written ...)

#### The Tree Tool Views

(... to be written ...)

#### The Output Tool Views

(... to be written ...)

### Sistemi di gestione dei progetti

Un progetto fa affidamento su qualche tipo di sistema di gestione dei progetti. &kdevelop; fornisce quattro sistemi di gestione dei progetti che possono essere selezionati quando il programmatore crea un nuovo progetto.

- I Progetti Automake usano gli strumenti standard di sviluppo &gnu;.

- I Progetti QMake usano il gestore di progetti Qmake di Trolltech

- I Progetti ANT usano il gestore di progetti ANT di Apache per lo sviluppo con Java.

- I Progetti personalizzati richiedono che si gestiscano i propri `Makefile`.

#### Progetti automake

I progetti creati con il gestore di progetti automake di &kdevelop; rendono molto facile per gli sviluppatori l'uso degli strumenti standard di sviluppo &gnu;. Essi forniscono

- una migliore generazione dei `Makefile` e

- un modo ottimale e sicuro per adattarsi velocemente a sistemi diversi usando gli script `configure` generati da autoconf.

#### QMake Projects

Per gli sviluppatori che amano la flessibilità del sistema qmake di &qt;, &kdevelop; fornisce la possibilità di gestire i progetti basati su qmake (file .pro) all'interno della GUI.

Per ulteriori informazioni sul gestore di progetti QMake vedere la guida qmake User Guide che dovrebbe essere inclusa nella propria distribuzione, oppure vedere il nel sito della documentazione di TROLLTECH dove si trova la documentazione di QMake della propria versione del toolkit in C++ di sviluppo di applicazioni GUI con Qt.

#### ANT Projects (Java Projects)

Gli sviluppatori Java potrebbero voler usare il gestore di progetti ANT di Apache per i loro progetti. Per impostare un nuovo progetto ANT con &kdevelop; selezionareNuovo Progetto...Java Ant Project Application.

Per ulteriori informazioni vedere la home page The Apache Ant Project.

#### Custom Projects

Se si preferisce gestire da soli i propri `Makefiles` per il proprio progetto si può usare l'opzione custom project di &kdevelop;. Questo potrebbe essere fattibile in progetti strutturati in modo non usuale o se si vuole mantenere il pieno controllo sul processo di `make`.

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

#### Come distribuire la propria applicazione

La distribuzione della propria applicazione richiede che l'utente finale abbia installato nient'altro che:

- un compilatore appropriato,

- un linker e

- le librerie di sviluppo appropriate

come accade frequentemente per le applicazioni C++. Ma si possono distribuire anche i pacchetti binari dell'applicazione. In entrambi i casi, l'utente finale del prodotto non deve avere installato &kdevelop;.

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.

Specialmente nelle applicazioni multi-linguaggio, i traduttori non lavorano con il codice sorgente, eccetto i casi che richiedono correzioni per abilitare il supporto alla traduzione.

## Configurare &kdevelop;

&kdevelop; is a very powerful and flexible IDE which offers many ways to taylor it to your needs. To start configuration select Settings Configure KDevelop.... This will cause the configuration dialog to pop up consisting of a selection window to the left and the configuration dialog on the right hand side whose contents will vary upon the configuration item you did select.

Select a configuration item

We will discuss these configurations in a different order, split up into the main topics of General Configuration, Configuring the Documentation Tree, and Advanced Configuration which makes for a more intuitive reading.

If you want directly look up a certain configuration item use one of the following links.

- General
- Plugins
- Source Formatter
- User Interface
- Editor
- Abbreviations
- Tools Menu
- External Tools
- Code Snippets
- File Selector
- Documentation Tree

### General Configuration

General configuration concerns the more common tasks of tayloring &kdevelop; as there are:

- General Setup

- Selecting the User Interface

- Source Edit Tasks

  - Selecting an Editor

  - Selecting a Source Format Style

  - Setting Up the Code Snippets Tool

- Configuring the File Selector

#### General Setup

The General configuration dialog allows you to define some basic &kdevelop; behaviour which seldom will change in everyday work. This concerns:

- General project options as

  - defining a default parent directory &kdevelop; shall use for new projects.

  - deciding whether you want &kdevelop; to automatically load the project you last worked on.

- Selecting a font for the most commonly used output view windows, namely

  - the Messages Output View &kdevelop; uses to communicate e.g. compilation progresses, and

  - the Application Output View which will show error and state information concerning a running application.

- Some common behaviour concerning the displayed lines in the Messages Output View window, namely

  - whether long lines will wrap around, and

  - if directory entry and exit messages issued by `Make` will be shown.

- The level of detail of messages concerning the compilation process shown in the Messages Output View window.

The general configuration dialog

##### Load last project on startup

Mark this checkbox if you want to continue to work with the last project you worked on. This will cause &kdevelop; to automatically load this project on startup. It will usually be shown in the state you left work so you can readily proceed.

##### Default projects directory

By default, &kdevelop; uses a common parent directory for all new projects. Enter the absolute path of this common directory in the box or select it from your directory structure. &kdevelop; will place the any new project here as a subdirectory.

You may of course change the directory path of a new project at the time you set it up in the &appwizard;.

##### Messages Output View window font

To select a font suitable for the Messages Output View window press the Window Font button showing the currently selected font (it says Luxi Sans in the above illustration). The &kde; standard Select Font dialog will pop up from which you may select the font to be used.

On first startup, &kdevelop; initializes this font setting to the standard font for which your &kde; user has been configured. This setting is fixed, so if you alter Preferences Appearances & Themes Fonts in the Control Center, this will not effect this &kdevelop; font selection. You will have to explicitely reselect the Messages Output View window font.

##### Line wrapping

By default, &kdevelop; will wrap long lines around in the Messages Output View window so that valuable information will not be easily overlooked. In some cases this will clutter long message lists. Remove the checkbox mark if you do not want the lines wrap around.

There is an alternative way to switch the line wrapping. Just right click in the Messages Output View window and mark/unmark the Line Wrapping entry in the menu which will pop up.

##### Directory navigation messages

The `Make` tool usually will display messages like Entering directory, or Leaving directory when it switches the directories it currently works in. As this clutters the messages list in the Messages Output View window, &kdevelop; suppresses those messages by default. Mark the checkbox if you want to protocol which directories `Make` worked in.

Changes in this setting effect the processing of new messages only. Old directory navigation messages will be kept visible when you switch this feature off.

##### Compiler output

&kdevelop; preprocesses the messages the Messages Output View window receives during the build processes in order to filter superfluous information. You can control the level of detail &kdevelop; will display using the radio buttons in this field.

Very Short

  Displays only warnings, errors, and the filenames which are compiled.

Short

  Suppresses all compiler flags and formats the output to be more readable.

Full

  Displays all output messages unmodified.

There is an alternative way to switch the compiler output detail. Just right click in the Messages Output View window and select the according detail level from the popup menu.

##### Application Output View window font

The Application Output View window is used to display error and state information from applications which are run from inside &kdevelop;. These are informations the applications usually sends to the console when run stand-alone. So you do not need to leave the IDE when testing the application you currently work on.

To select a font suitable for the Application Output View window press the Window Font button showing the currently selected font (it says Luxi Sans in the above illustration). The &kde; standard Select Font dialog will pop up from which you may select the font to be used.

On first startup, &kdevelop; initializes this font setting to the standard font for which your &kde; user has been configured. This setting is fixed, so if you alter Preferences Appearances & Themes Fonts in the Control Center, this will not effect this &kdevelop; font selection. You will have to explicitely reselect the Application Output View window font.

#### Selecting the User Interface

As already said in the Available User Interface Modes chapter there are four different ways the &kdevelop; work area may be set up, namely:

- IDEAl Mode

- Child Frame Windows Mode

- Tabbed Pages Mode

- Toplevel Windows Mode

To switch the user interface mode select Settings Configure KDevelop... from the menus. The Customize KDevelop dialog will pop up, where you have to select User Interface in the left hand tree. This will display the followig settings dialog to the right.

Selezionare una modalità dell'interfaccia utente

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

#### Selecting an Editor

&kdevelop; allows you to select your favorite text editor tool. Mark the Editor entry in the left hand side selections tree of the Configure KDevelop window. The following dialog will be displayed to the right.

Select an editor

To select a new editor, click on the arrow on the drop down list field. Depending on the editor parts interfaces your &kde; version has compiled in you will be provided with a list of editors you may select from (see the Important note below for this). Click on the editor of your liking and press OK. Currently there are tree possibilities:

Embedded Advanced Text Editor

  This is the &kde; standard Kate editor part.

Embedded Vim Component

  This provides the look and feel of the base Linux vi editor.

  - You need to have a suitable Vim application installed. Have a look at the KVim website for more information.

  - Furthermore you need to configure the KParts Vim component in the &kde; Control Center (KDE Components Vim Component Configuration) before you can use it.

Qt Designer Based Text Editor

  This is the editor Qt provides in its Designer component.

These editor interfaces are fully integrated in the &kdevelop; IDE concept. Particularly the possibility to jump to the offending source code line by just clicking on an error message in the Messages Output View window has been provided.

Changing the editor will not effect already open files. There are two possibilities to proceed. Either close all open text windows and reopen them one by one. Or simply close the whole project and reopen it again. The windows will then automatically open under the new text editor interface.

KDevelop lets you use editor interfaces which have registered with &kde; and that provide a KatePart interface. If you miss one one of the selections shown above check your &kde; installation if the corresponding KPart was correctly installed.

#### Selecting a Source Format Style

&kdevelop; automatically formats a source text in a predefined style. This style is highly configurable. Select Settings Configure KDevelop... from the menubar. The Customize KDevelop dialog will pop up, where you have to select Source Formatter in the left hand tree. This will display a series of three settings dialog tabs to the right, namely a General Formatting Setup, a Indentation Style Setup, and a Other Formatting Setup.

Any style changes apply to newly entered text only. If you want to change the formatting style of an already existing source text you will have to explicitely use the Edit Reformat Source command.

The exact outcome of these style formatting definitions depends on the editor you use. Currently, most settings are taylored to the Kate editor part (the Embedded Advanced Text Editor). Some other editors (e.g. the Qt editor) may rely on their own configuration settings. You will have to experiment in this case to find out the exact effects of the style settings provided here.

Tere may be incompatibilities between the configuration style settings provided here and the editor you use up to the extent that in extreme cases it even might destroy your files. Make sure you have a backup of your source files before you try out these settings with an none KDE standard editor.

##### General Formatting Setup

The General tab of the Source Formatter dialog allows you to select one out of five predefined source format styles.

Source format style general setup

A formatted source example will be displayed in the field to the right. If none of the predefined styles is to your liking, you may press the top User defined radio button and define your own source formatting style preferences on the other two tabs which will become available then.

Currently only the predefined source formatting styles will be demonstrated by an example text. If you decide to define your own style, no example display will be available. You have to experiment on an actual source text to taylor the settings to your liking.

##### Indentation Style Setup

Proper indentation is the main means to enhance readability of a source text. I you selected the Indentation tab of the Source Formatter dialog you will be presented with a series of indentation formatting choices grouped into three boxes as following.

Source format indentation style setup

###### Default Settings

The preset format choices will cause the source text to resemble the ANSI formatting style:

    namespace foospace
    {
      int Foo()
      {
        if (isBar)
        {
          bar();
          return 1;
        }
        else
          return 0;
      }
    }

###### Defining Indentation Width and Characters

The radio buttons grouped in the Filling group define how indents in the source text will be drawn.

Use tabs

  This will cause the editor to insert a tab character for each indentation level. The tab width is predefined in the editor settings (8 or 4 character columns usually). Use Settings Configure Editor... to redefine it.

  The actual tab width definition procedure depends on the editor you selected in the Selecting an Editor configuration step. You will have to look up the corresponding editor help to find out.

Use spaces

  If you select this radio button, the editor will enter a number of spaces for each indentation level. Change the number from the default 2 to the indentation width you prefer.

###### Indented Entities

This defines which of the (C/C++) entities will be formatted with an extra indent beyond the current indentation level.

By default only namespaces and labels will be extra indented. You may want to experiment with various settings to taylor those extra indents to your liking.

###### Continuation

The settings grouped here apply to those cases where the source formatter automatically wraps around long source lines. It takes two special cases in account, namely that in deeply nested indents there should remain enough room for the source and that conditionals should get extra indent levels on continuation to make them stand out properly.

This applies to static word wrap cases only where a fixed maximum line width is used in the source text. If you set up your editor to dynamically wrap around long lines in display only (which is possible in the Kate editor part) the effects of these settings usually will not show.

Maximum in statement

  This setting limits the maximum possible indentation for the continuation lines so that enough space will remain to keep the text readable. No continuation line will ever be indented beyond the number of columns you selected in this field.

  The default is set to 40 character columns (half a standard 80 column page). You may want to increase this value to account for wider paper (e.g if you use landscape printing for your sources). Or decrease the value accordingly to take larger margin settings of your printouts into account.

Minimum in conditional

  Conditionals or source following e.g. an assignment operator should usually get an extra indent on continuation lines in order to keep the text readable. The amount of this extra indent is defined here.

  The default is set to Twice current which means that continued conditionals will get an extra indent level of the standard indentation size you selected in the Filling group. You may change this extra indent to another fixed width (including zero) using the arrows or by entering the value directly.

##### Other Formatting Setup

Other source format style settings

###### Controlling the position of braces

The radio buttons the (somewhat misnamed) Brackets group control the position of block delimiting braces in a (C/C++) source text. There are three possibilities from which you can select.

Break

  This inserts a line break before each opening brace. Both delimiting braces of any block will be put at the same indentation level as the block head statement.

      namespace foospace
      {
        int Foo()
        {
          if (isBar)
          {
            bar();
            return 1;
          }
          else
            return 0;
        }
      }

Attach

  This will keep the opening brace of a block in line with the block head statement. Closing braces will be on the same indentation level as the block head statement. The else of an if statement will be kept in line with the closing brace of the preceding block.

      namespace foospace {
        int Foo() {
          if (isBar) {
            bar();
            return 1;
          } else
            return 0;
        }
      }

Linux Style

  This is a compromise of the above listed styles. Functional block delimiting braces will be put on extra lines. Braces opening a block in a conditional or loop statement will be kept in line.

      namespace foospace
      {
        int Foo()
        {
          if (isBar) {
            bar();
            return 1;
          } else
            return 0;
        }
      }

###### Controlling extra spaces

By default &kdevelop; does minimize the use of spaces in source texts.

    if (isBar(fooArg)==barValue)

You may enhance readability if you force the source formatter to insert extra spaces in special positions.

Add spaces around parentheses

  In fact what is meant is to add spaces around the text put in parentheses. This enhances the readbilitiy of function arguments and conditionals.

      if ( isBar( fooArg )==barValue )

Add spaces around operators

  This will put spaces around assignment and comparison operators to enhance the readability.

      if (isBar(fooArg) == barValue)

###### Controlling the formatting of one-line constructs

There are a few cases where you don't want the source formatter to split a long line apart. For C/C++ code this can be controlled here.

Keep one-line statements

  This keeps single line statements together in some situations even if they exceed a fixed maximum line length.

Keep one-line blocks

  This keeps single line blocks together in some situations even if they exceed a fixed maximum line length.

#### Setting Up the Code Snippets Tool

When editing in &kdevelop; you can store often used parts of code as Code Snippets. To configure the capabilities of the code snippets part select Settings Configure KDevelop... from the menubar. The Customize KDevelop dialog will pop up, where you have to select Code Snippets in the left hand tree. This will show the following dialog in the right hand side.

Configuring the Code Snippets tool

##### Activate snippet preview

Mark the Show snippet's text in tooltip checkbox if you want to view the stored text in a tooltip window whenever you keep the mouse cursor over the title of that snippet.

##### Working with snippet variables

The Code Snippets tool allows for a variable text in predefined places any time you insert a snippet into a file. To accomplish this Code Snippets provides its own variables' mechanism. You can set up it's behaviour in the Variables group.

Delimiter

  The Code Snippets tool distinguishes variables in the text by surrounding the variable name with special delimiter symbols. To use your own delimiter symbol, change the predefined $ character in the Delimiter field.

Input method for variables

  - Single dialog for each variable within a snippet – will in turn pop up a separate dialog for each variable which the tool finds when inserting the selected code snippet.

  - One dialog for all variables within a snippet – will pop up a common dialog where the user has to fill in the values of all variables before the snippet will be inserted

#### Configuring the File Selector

&kdevelop; provides a File Selector plugin which, when loaded at startup, allows to navigate to any file or directory in the system.

The file selector (IDEAl mode)

The behaviour of the File Selector can be highly configured. Select Settings Configure KDevelop... from the menubar. The Customize KDevelop dialog will pop up, where you have to select File Selector in the left hand tree. This will show the following dialog in the right hand side.

Configuring the file selector

##### Configuring the toolbar

There is a toolbar on top of the File Selector which can be configured as usual in the Toolbar group.

##### Add an action to the toolbar

1. Select an item in the right hand Selected actions list after which the new action should be inserted.

2. Select the action to be inserted in the left hand Available actions list.

3. Click the right (upper) arrow between both lists.

   The action will be removed from the Available actions list and inserted into the Selected actions list below the selected item.

##### Remove an action from the toolbar

1. Select the item to be removed in the right hand Selected actions list.

2. Click the left (lower) arrow between both lists.

   The selected item will be removed from the Selected actions list and put back into the Available actions list.

##### Reorder the actions on the toolbar

1. Select the action to be moved in the right hand Selected actions list.

2. Click the up or down arrow to the right of this list.

   The selected item will be moved up or down the Selected actions list.

##### Defining when the contents should change

Updating the contents in the File Selector window takes time and resources, esp. when changing to another directory. Therefore File Selector is set up by default in such a way that its contents change only on demand, i.e. when you select another directory or when you explicitely want to refresh its contents.

You can however configure the File Selector to immediately reflect certain changes in your work. The settings in the Auto Synchronization group of the configuration dialog are responsible for this.

You can always update the contents of the File Selector by pressing the Reload button in the toolbar. This is not availble by default, however. You must insert it there first.

##### The file selector may update its content...

...When a document becomes active

  If you select this checkbox, the contents in the File Selector window will be updated whenever you go to another already open document, e.g. when you click on the tab of the according edit window in IDEAl mode. If necessary the File Selector will switch to the directory this file belongs to and update the display to show the actual contents in there.

...When a document is opened

  If you select this checkbox, the contents in the File Selector window will be updated whenever a document will be opened, e.g. by the File Open menu. If necessary the File Selector will switch to the directory this file belongs to and update the display to show the actual contents in there.

...When the file selector becomes visible

  If you select this checkbox, the contents in the File Selector window will be updated whenever it gets visible again. If necessary it will switch to the directory the actual document belongs to and update the display to show the actual contents in there.

You may freely combine these settings to taylor the actualization behaviour of the File Selector to your liking.

##### Controlling the history in the comboboxes

There are two comboboxes on top and bottom of the File Selector contents window which control the directory to be diplayed (top combobox) and the filters to be applied to the file display (bottom combobox). A history of the most recent settings is kept in the selection field of each combobox. You can configure the number of history entries as follows.

Remember locations

  Enter here the maximum number of directory selections the upper combobox shall remember.

Remember filters

  Enter here the maximum number of filter definitions the lower combobox shall remember.

##### Controlling what should be remembered between sessions

By default the File Selector is set up so that it shows the display of the most recent session again at the next &kdevelop; startup. You may change this behaviour in the Session configuration group.

If &kdevelop; was automatically restarted by the KDE session manager the changes in these settings will have no effect. In this case location and filter settings of the most recent KDE session will always be restored.

Restore location

  Remove the checkbox mark here if you don't want the displayed location be remembered between sessions.

  If you selected one of the automatic update settings the displayed location might automatically change regardless what has been remembered from the recent session.

Restore filters

  Remove the checkbox mark here if you don't want the filters applied to the display be remembered between sessions.

### Configuring the Documentation Tree

(... to be written ...)

### Configurazione avanzata

(... to be written ...)

#### Plugin

(... to be written ...)

#### Abbreviations for the Word Completion

(... to be written ...)

#### Adding &kde; Standard Applications to the Tools Menu

(... to be written ...)

#### Adding External Applications to Menus

(... to be written ...)

##### Adding to the Tools Menu

(... to be written ...)

##### Adding to the File Context Menu

(... to be written ...)

##### Adding to the Directory Context Menu

(... to be written ...)

## Getting Started—the &appwizard;

In &kdevelop; lo sviluppo di software è organizzato in progetti. Un progetto racchiude tutto ciò che comprende un completo lavoro di programmazione: file sorgenti, file di dati aggiuntivi e tutte le funzioni di gestione veramente importanti come il sistema make, così come l'accesso a tutti i componenti e agli strumenti aggiuntivi necessari per rendere l'applicazione funzionante.

Organizzare tutto il lavoro di sviluppo in progetti permette di avere tutti compiti facilmente sottomano. Questo è molto pratico ad esempio, come succede spesso, se si lavora su diverse applicazioni contemporaneamente. Si indica a &kdevelop; di aprire il progetto con cui si vuole lavorare e si procede dal punto da dove si era lasciato.

### Nuovi progetti

Quando si vuole iniziare un nuovo progetto di programmazione, devono essere svolte parecchie procedure di setup. Deve essere impostata una struttura di directory iniziale, devono essere creati i file sorgente e header iniziali, deve essere inizializzato il sistema make, ecc.

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

Usando la procedura guidata per le applicazioni sono necessarie solo poche fasi per iniziare un nuovo progetto:

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 &appwizard; to set up all initial stuff, directory structure, starting header/source file templates, and management tools, like e.g. an initial make skeleton, etc.

Voilà—that's all. &appwizard; will have provided you with a primary functional set of programming files, where you can readily start working.

Adesso si scenderà maggiormente nei dettagli...

#### Fasi iniziali

Per creare un nuovo progetto con &kdevelop;, selezionare Nuovo Progetto... dal menu Progetto. Apparirà la finestra di dialogo Crea nuovo progetto mostrando la pagina iniziale Generale:

Finestra di dialogo per creare un nuovo progetto

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

##### Selezionare il linguaggio di programmazione e il tipo di applicazione

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 there are:

- Ada

- C

- C++

- Database (SQL Projects)

- Fortran

- Haskell

- Java

- PHP

- Pascal

- Perl

- Python

- Ruby

- Shell (Scripts for the Bash Shell)

Precisamente, queste cartelle non contengono i veri strumenti di programmazione. Esse contengono modelli predefiniti che possono essere usati come punto di partenza per la programmazione in quel particolare linguaggio. Per avere un'idea di quello che viene fornito, aprire le cartelle una dopo l'altra. In alcune di esse saranno presenti una serie di sottocartelle, mentre in altre ci saranno alcuni semplici elementi. Queste sottocartelle organizzano i modelli disponibili a seconda dei vari compiti, mentre gli elementi hanno il nome dei modelli che possono essere selezionati.

Non si scenderà ulteriormente nei dettagli su quale compito viene svolto dai vari modelli, ma è semplice scoprirlo. Quando si seleziona un elemento vengono fornite alcune informazioni nei campi a destra. Nel campo più in basso si troverà una breve descrizione di cosa dovrebbe fare il modello. Nel campo più in alto, se disponibile, verrà mostrata un'immagine dell'applicazione che verrà prodotta dal modello nel caso venisse compilata e avviata senza modifiche. Normalmente questa immagine è uno screenshot della finestra principale dell'applicazione.

Come punto di partenza, selezionare il modello che si adatta meglio agli scopi della propria applicazione. Poi inserire le informazioni delle proprietà generali nel campo in basso come sarà mostrato nel prossimo capitolo.

###### Selecting a Project Management System

Each template is bound to a specific Project Management System. Currently there is no direct means to freely select such a Project Management System. You have to find a template which suits your needs or alter your project accordingly after creation.

##### Fornire le informazioni generali

La parte più in basso della pagina Generale della finestra di dialogo Crea nuovo progetto è formata da un gruppo di campi chiamati Proprietà. Si devono fornire alcune informazioni generali del proprio progetto in modo che la procedura guidata sappia come costruire la struttura iniziale.

###### Nome dell'applicazione

Your application needs a name of course. Enter this in the uppermost Properties field, called Application Name. We use MyApp as an example.

Quando viene inserito, si noterà che la procedura guidata rifiuta i caratteri speciali. Gli unici caratteri ammessi sono:

- caratteri maiuscoli e minuscoli

- numeri

- il carattere underline

La principale causa di queste restrizioni consiste nel fatto che la procedura guidata userà il nome dell'applicazione come base per alcuni nomi di classi. Quindi il nome dell'applicazione dovrà attenersi alle regole del linguaggio di programmazione che viene usato.

###### Directory del progetto

L'altra causa può essere osservata nella linea inferiore dell'area Proprietà. È chiamata Posizione Finale e mostra la directory dove la procedura guidata creerà l'applicazione.

Mentre si scrive il nome dell'applicazione si noterà che la procedura guidata ripete il proprio input alla fine della linea Posizione Finale, usando solo i caratteri minuscoli.

Quindi si deve selezionare con cura il nome della propria applicazione. Se si usa il nome di una directory già usata la procedura guidata non permetterà di continuare con la prossima fase tenendo disattivato il pulsante Successivo > (rendendolo grigio). Tuttavia in questo caso la procedura guidata avvertirà aggiungendo (dir./file già esistente) alla linea Posizione finale .

###### Il percorso di partenza

Ci sono due modi per scegliere un altro percorso per la propria applicazione. Uno consiste nel selezionare un altro nome. Tuttavia non è sempre attuabile. In alternativa si può selezionare un altro percorso della directory dell'applicazione.

Questo è fatto nella seconda riga di Proprietà, chiamata Posizione. Quello che viene inserito è il percorso di partenza dello sviluppo della nuova applicazione. La procedura guidata aggiunge il nome dell'applicazione a questo percorso quando inizializza il nuovo progetto. Il risultato è mostrato nella linea Posizione finale, in modo da avere un miglior controllo di quello che succede.

&appwizard; 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. In our case we have &kdevelop; set up to use `/home/devel/projects/` as initial path for new projects.

Cambiare il contenuto del campo Posizione in modo che la directory di sviluppo dell'applicazione mostrata nella Posizione finale sia univoca.

Accertarsi che il percorso che si inserisce nel campo Posizione sia esistente. In caso contrario non si potrà continuare con la prossima fase. La procedura guidata avvertirà nel caso non esistesse il percorso aggiungendo (non valido) alla linea Posizione finale.

###### Informazioni personali

I campi seguenti non sono così cruciali. Inserire il proprio nome (ad esempio il nome del responsabile dell'applicazione) nel campo Autore, e un indirizzo di email valido nel campo Posta elettronica, in modo che gli utenti possano fornire un feedback per l'applicazione.

1. La procedura guidata riempie questi campi con alcuni valori di default, presi dalle impostazione per l'indirizzo Email del centro di controllo KDE. Se i valori di default dei campi Autore e Posta elettronica non sono appropriati si dovrebbe controllare la propria configurazione di posta nel centro di controllo KDE.

2. Se questa informazione è disponibile, verrà integrata dalla procedura guidata nel modello dell'applicazione. Ad esempio nei programmi KDE C++ la si troverà vicino all'inizio del file `main.cpp`.

3. Di tutti i campi, Posta elettronica è opzionale, tenuto conto che non tutti gli sviluppatori hanno accesso a Internet. Tuttavia se si desidera si può lasciare il campo vuoto e procedere.

###### Informazioni sulla versione e sulle licenze

Infine inserire un numero di versione per la propria applicazione nel campo Versione e selezionare la licenza con la quale rilasciare la propria applicazione nel menu Licenza.

If you select an application type for which the &appwizard; provides common source template texts (e.g. C/C++), you may view the license notification text on the third page of this Create New Project dialog (see the Supply header/source templates chapter below).

Se si seleziona Personalizzato dal menu Licenza si dovrà inserire il testo della licenza.

Sia la versione che l'informazione sulla licenza saranno integrati nei modelli in un formato appropriato per il tipo di applicazione selezionata.

Quando sono state inserite correttamente tutte le informazioni, premere il pulsante Successivo > per procedere nei seguenti capitoli.

#### Fornire le informazioni del Version System

Nella seconda fase la procedura guidata mostrerà la pagina Version Control System dove si può decidere quale version control system si vuole usare.

Questo documento si limita a quanto è necessario per la creazione di progetti. Per ulteriori informazioni su CVS vedere il capitolo Usare CVS

##### Nessun Version Control System

Inizialmente è selezionato Nessuno nel menu Sistema di controllo versione, e la pagina è vuota. Se non si vuole usare un version control system, cliccare sul pulsante Successivo > e proseguire.

##### Usare CVS

Otherwise you must reselect the version control system you want to use from the Version control system tab. We use &cvs; for our example. If you select this, the &appwizard; will redisplay the page, now showing a series of fields you must fill in.

Impostare un nuovo progetto con il CVS

Un version control system come &CVS; (che significa Concurrent Versions System) conserva copie di file di progetto selezionati in una sorta di database. Se si usa &CVS; si possono caricare (commit) o scaricare questi file nella propria directory del progetto (checkout, o update). La particolarità consiste nella struttura in cui sono immagazzinati i file che permette di ripristinare un precedente stato di sviluppo. &CVS; permette a diversi progettisti di collaborare facilmente ad un grande progetto senza che si disturbino a vicenda.

##### Radice CVS

&cvs; deve amministrare il database che è costituito dai file di progetto. Per realizzare questo conserva alcune informazioni speciali in una propria directory chiamata radice &cvs;. Quindi il primo passo nell'impostazione del &cvs; per il progetto consiste nell'indicare a &kdevelop; dove è situata questa directory radice.

radice &cvs; locale. Ci sono principalmente due possibilità, a seconda che si voglia usare un database CVS locale o uno che è mantenuto su un server remoto. Se si sviluppa in proprio, si potrebbe usare il database &cvs; come una sorta di sistema di backup sul proprio computer. Normalmente questo è impostato sulla propria directory home e ha come nome `cvsroot`. Potrebbe essere simile a questo:

``/home/devel/cvsroot`` (dove `devel` indica semplicemente l'utente developing, ad esempio)

Di fatto, questa è la forma corta. Esattamente, la radice locale del &cvs; dovrebbe essere indirizzata usando il prefisso `:local:`. La forma breve è permessa solo nei casi in cui il nome del file inizia con unabarra (`/`). Il nome completo per l'esempio sarebbe esattamente così:`:local:/home/devel/cvsroot`

Inserire il nome della directory radice del &cvs; che il proprio sistema ha impostato nel campo Radice CVS. Per principio si può selezionare ogni nome, anche database multipli, ma una volta impostata è consigliabile attenersi alla radice &cvs;.

Inizializzare una nuova radice &cvs;. Se non esiste ancora una radice &cvs;, &kdevelop; può comandare a &cvs; di crearne una nella directory fornita. Selezionare la casella Init root sotto al campo Radice CVS.

Come detto in precedenza, &kdevelop; comanda solo al sistema &cvs; di inizializzare una nuova radice &cvs;. Non fa nulla da solo nella directory. Fortunatamente, &cvs; è abbastanza saggio da controllare se esiste già una directory radice. Perciò non succede nulla di male se si seleziona inavvertitamente la casella Init root in una directory radice già esistente.

Radice &cvs; remota. Ci sono situazioni dove il database &cvs; deve essere mantenuto su un server remoto, specialmente quando diversi sviluppatori lavorano allo stesso progetto. In questo caso si deve inserire l'URL della radice &cvs; di questo server nel campo Radice CVS. Per esempio, se si vuole accedere al server &cvs; di &kde;:

``:pserver:mylogin@cvs.kde.org:/home/kde`` dove `mylogin` indica il nome che è stato impostato nell'account &cvs; di &kde;)

##### Tipi di server &cvs; remoti

Principalmente ci sono due tipi largamente usati di server &cvs; remoti, il pserver che usa un protocollo non cifrato protetto da password e il server ext che usa il trasferimento dati cifrato rsh o ssh. Sono distinti dal prefisso dell'URL usato:

`:pserver:`

per un server protetto da password non cifrato, e

`:ext:`

per un server cifrato di tipo rsh o ssh. Per esempio

``:ext:mylogin@cvs.cervisia.sourceforge.net:/cvsroot/cervisia``

accede alla radice &cvs; dello strumento di gestione largamente usato Cervisia sul server SourceForge.

Se si vuole usare un server cifrato rsh o ssh per l'accesso &cvs; si deve indicare a &kdevelop; il protocollo di cifratura da usare. Inserire `rsh` o `ssh` nel campo CVS_RSH della pagina Version Control System della finestra Crea nuovo progetto.

Bisogna fare attenzione se si usa un server cifrato per &cvs; con &kdevelop;. Vedere il capitolo Usare CVS per i dettagli.

##### Il repository &cvs;

Si è indicato a &kdevelop; dove risiede la radice &cvs; che gestisce il database versioning e come accedervi. Adesso si deve indicare a &kdevelop; sotto quale nome si vogliono salvare i file di progetto nel database. Questa locazione dove i file di progetto vengono salvati è detta repository.

In principio si può usare qualunque nome per il repository &cvs; fintanto che esso aderisce alle specifiche per i nomi di file. Tuttavia, molti sviluppatori usano semplicemente il nome stesso dell'applicazione. &CVS; costruirà una directory con questo nome nella radice &cvs;, perciò se si usa il nome dell'applicazione sarà più facile da trovare.

Just enter the repository name you want to use in the CVS repository field of the Create New Project Version Control System page. In our example this is: `MyApp`

Si eviti di usare un repository già esistente! Il sistema &CVS; non avverte in caso di file duplicati ma elimina tutto quello che non produce un conflitto formale. Si rovinerà tutto!

##### Campi rimanenti

Non c'è molto altro lavoro da fare. La procedura guidata ha già impostato i campi rimanenti per voi. Nel dettaglio:

Il campo Tag del Vendor è usato solo per ragioni di compatibilità. Si può mantenere il valore di default vendor che viene inserito dalla procedura guidata.

Il campo Messaggio permette di commentare i contenuti iniziali di &cvs;. Usare qualunque testo si desideri oppure lasciare il default nuovo progetto che viene inserito dalla procedura guidata.

Il Tag di release contiene il nome che etichetta lo stato iniziale del progetto. Una tale etichetta definisce all'interno del repository &cvs; un certo punto dal quale si può in seguito accedere a quello stadio di sviluppo. (Ulteriori informazioni nel capitolo Usare CVS)

La procedura guidata mette un valore di default avvia che è una buona proposta. Lasciare questa.

Fino al momento della costruzione del progetto, &kdevelop; non sapràse qualche informazione tra tutte queste è sbagliata. Sarà il sistema &CVS; a capire questi errori quando tenterà di costruire il repository. Quindi si deve controllare la finestra Messaggi di &kdevelop; quando il progetto viene creato nella fase finale. Se c'è stato qualche errore con le impostazioni di &cvs; nella maggior parte dei casi si vedranno messaggi di errore come questi:

    * cd '/home/devel/test' && cvs -d '/home/devel/mycvsroot' \
      import -m 'nuovo progetto' '' 'vendor' 'avvia' &&\
      sh /opt/kde3/share/apps/kdevcvs/buildcvs.sh . '' \
      '/home/devel/mycvsroot'
    * cvs [import aborted]: /home/devel/mycvsroot/CVSROOT: No such file or
      directory
    * *** Exited with status: 1 ***

Se accade questo si deve impostare manualmente &cvs; (&kdevelop; dovrebbe aver inizializzato con successo i file del progetto) o cancellare la directory del progetto e ricominciare da capo con il comando Nuovo Progetto... dal menu Progetto.

After you have entered all &CVS; related information, click the Next > to go on.

Se si vuole correggere un errore nella pagina precedente, premere il pulsante < Precedente. La procedura guidata ricorderà le impostazioni della pagina attuale, in modo da poter procedere facilmente quando si ritornerà indietro.

#### Fornire i modelli dei file header/sorgente

Nel prossimo passo si imposteranno alcune informazioni comuni che si vogliono includere nei file sorgente e header.

Nelle rispettive pagine vengono forniti i modelli dei file header e sorgente per le applicazioni C/C++. Per gli altri linguaggi potrebbe essere disponibile solo il modello per i file sorgente, e in alcuni casi si troveranno le pagine dei modelli vuote.

Se la pagina viene usata, sarà riempita dalla procedura guidata con alcuni commenti, che per le applicazioni C++ appariranno così:

    /***************************************************************************
     *   Copyright (C) 2003 by Nome                                            *
     *   io@io.it                                                              *
     *                                                                         *
     *   This program is free software; you can redistribute it and/or modify  *
     *   it under the terms of the GNU General Public License as published by  *
     *   the Free Software Foundation; either version 2 of the License, or     *
     *   (at your option) any later version.                                   *
     *                                                                         *
     *   This program is distributed in the hope that it will be useful,       *
     *   but WITHOUT ANY WARRANTY; without even the implied warranty of        *
     *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the         *
     *   GNU General Public License for more details.                          *
     *                                                                         *
     *   You should have received a copy of the GNU General Public License     *
     *   along with this program; if not, write to the                         *
     *   Free Software Foundation, Inc.,                                       *
     *   59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.             *
     ***************************************************************************/

Gli altri modelli forniranno simili informazioni in un formato adatto alle definizioni del linguaggio di programmazione usato.

Come si potrebbe aver notato il gestore delle applicazioni usa le informazioni che sono state fornite nella pagina Generale della finestra di dialogo Crea nuovo progetto, cioè i contenuti dei campi Autore e Posta elettronica. Anche le informazioni sulla licenza vengono inserite a seconda della selezione effettuata nel menu Licenza.

##### Come modificare i modelli

Quando in seguito si indicherà a &kdevelop; di impostare un nuovo file sorgente e/o header, verranno elaborati i modelli impostati nella finestra di dialogo Crea nuovo progetto. Le informazioni fornite saranno incluse nei file sotto forma di intestazione di documentazione prima dell'inizio della parte di codice.

You are not restricted to plain text however. &kdevelop; knows of several variables which allow you to include actual information in the file. The &appwizard; did in fact use some such variables to insert the Author, Email, and License informations into the initial template text.

###### Includere informazioni di &doxygen;

Per esempio, se si vuole che la documentazione API di &doxygen; visualizzi alcune informazioni ulteriori del contenuto del file nella sua lista di file, si potrebbero includere le seguenti linee nel modello di file sorgente.

    /**
     * \file $MODULE$.cpp
     * \brief (inserire-qui-una-breve-descrizione).
     **/

Quando si crea un file sorgente, &kdevelop; sostituirà alla variabile `$MODULE$` il nome del file creato. Per esempio, se si crea una nuovo classe C++ chiamata `ASimpleTest` si vedranno le linee seguenti nel file `asimpletest.cpp`:

    /**
     * \file asimpletest.cpp
     * \brief (inserire-qui-una-breve-descrizione).
     **/

Si dovrà ancora fornire una breve descrizione dopo la parola chiave \brief, ma parte del lavoro è stato fatto automaticamente.

###### Il file della licenza

Come esempio si può includere un accenno al testo di licenza che si vuole usare nel modello. Per questo usare la variabile `$LICENSEFILE$` e aggiungere (ad esempio) questa linea:

    //   Vedere $LICENSEFILE$ per il testo completo della licenza.

La procedura guidata sostituirà `$LICENSEFILE$` con il nome del file dove si trova il testo completo della licenza, cioè:

    //   Vedere COPYING per il testo completo della licenza.

per la licenza GPL, o

    //   Vedere LICENSE.BSD per il testo completo della licenza.

se si decide di rilasciare la propria applicazione sotto licenza BSD.

Ci sono ovviamente molte altre variabili riconosciute da &kdevelop;. Vedere la sezione Modificare i modelli del capitolo Strumenti di Editing per ulteriori informazioni.

I modelli che vengono definiti diventeranno effettivi solo dopo che la procedura guidata ha creato il nuovo progetto. Si troveranno queste informazioni all'inizio dei file che sono creati durante il processo di sviluppo. Quando verranno creati i file iniziali la procedura guidata userà alcuni modelli standard predefiniti. Si dovranno adattare manualmente questi file alle proprie esigenze.

#### Compilare i file iniziali

È stato fatto quasi tutto. Nell'ultima pagina il pulsante Successivo > cambierà per diventare Fine.

Think twice before you click on it! You still have the option to revise everything by repeatedly using the < Back button. As the &appwizard; remembers all information you did input so far, it may be advisable for you to take the time and look back once again. In case you use local CVS, do not forget to double-check the CVS repository name (there should be no subdirectory with that name in the CVS root directory already—if it does, try another repository name).

If ever you don't want the new project be built, abort the Create New Project dialog by the Cancel button. Otherwise click Finish and watch in the Messages window how the &appwizard; initiates the project.

Se si vuole usare un sistema di versioning (&CVS;) ci sono effettivamente due percorsi. La procedura guidata costruirà prima le directory del progetto e i file, in seguito chiamerà il programma &CVS; che metterà nella finestra Messaggi il proprio output. Se capita qualche errore in queste fasi, il processo si fermerà, mostrando il messaggio di errore opportuno nella finestra.

In many cases when your new project has been set up this way, &kdevelop; will automatically load the source file(s) of one or more basically important modules so you can readily start work. (Which source modules will be displayed—if any at all—however depends on the template initially selected in the &appwizard;.)

Non dimenticarsi di fare un controllo preliminare di cosa ha fatto la procedura guidata. Per esempio si potrebbe voler modificare le informazioni di intestazione a seconda dei propri modelli. Queste si trovano normalmente nella sottodirectory `templates` nella propria directory di progetto. Saranno sufficienti alcune semplici operazioni di copia.

In seguito è consigliabile compilare il progetto iniziale prima di tentare di cambiare il codice. Nella maggior parte dei casi sarà possibile la compilazione. In questo modo si può capire se il progetto è stato impostato a seconda delle proprie necessità. In caso contrario, rimuovere semplicemente la directory del progetto (anche nella propria radice &CVS; se viene usata) e ripartire nuovamente.

Prima di compilare il nuovo progetto, controllare in Progetto Configurazione compilazione. Se sono visualizzate tre selezioni: default, optimized, e debug e quest'ultima è selezionata si deve mantenere questa configurazione oppure selezionare optimized.

A causa di alcune limitazioni nell'impostazione attuale di autoconf/automake non si dovrebbe per nessun motivo compilare nella configurazione default. Questo corromperà alcune impostazioni interne della directory, quindi `configure` si lamenterà quando si tenterà di usarlo in seguito nella configurazione optimized o debug.

(Questo si applica solo con queste capacita' di multiselezione. Se il tipo della propria applicazione fornisce solo la configurazione default, si deve ovviamente usare quest'ultima.)

### Dietro le quinte

È sempre consigliabile controllare l'output dei messaggi e tentare di capire cosa succede. Almeno in principio si dovrebbe sapere cosa accade quando la procedura guidata inizializza un nuovo progetto. Senza scendere nei dettagli si effettuerà un esame di questi messaggi per avere un'idea di cosa succede dietro le quinte.

If your project was set up for local &CVS; you will have got two series of messages of which the first set most probably was gone before you could thoroughly read, as &CVS; used the Messages window for its own purposes. So we caught both series in separate runs—set up the application twice, one time without &CVS;, then removed the directory and started over, this time setting the application up with &CVS;.

Si potrebbe voler seguire questa procedura se accade qualcosa di strano e non si possono recuperare i messaggi della prima parte del setup.

Si osserverà l'output di Messaggi in entrambi i casi:

- Sia Impostazione dell'applicazione che

- Impostazione del &CVS;.

#### Impostazione dell'applicazione

If you set up MyApp as in our previous example the &appwizard; should have printed the following messages (we re-arranged the output a bit for readability and you may click on a line to directly jump to its description):

    * perl /opt/kde3/share/apps/kdevappwizard/template-kapp/script \
      --author='Your Name' \
      --email='you@you.com' \
      --version='0.1' \
      --appname='MyApp' \
      --dest='/home/devel/projects/myapp' \
      --source='/opt/kde3/share/apps/kdevappwizard' \
      --license='GPL' \
      --licensefile='COPYING' \
      --filetemplates='h,/tmp/kde-devel/kdevelopcDE5Ja.tmp,\
                       cpp,/tmp/kde-devel/kdevelopsRrLab.tmp'
    * Making destination directory
    * Installing file templates
    * Installing license file
    * Installing admin directory
    * Installing GNU coding standard files
    * Installing Docbook template
    * Installing project file
    * Installing application framework
    * Installing application sources
    * Finished
    * *** Success ***

##### Chiamata allo script &perl;

Come si può vedere dalla prima linea, la procedura guidata chiama un programma &perl; con le impostazioni che sono state selezionate nella finestra di dialogo Crea nuovo progetto. Lo `script` risiede in una directory determinata dal tipo di applicazione selezionata nella parte superiore della pagina Generale della finestra di dialogo Crea nuovo progetto.

In our case this `script` is located in the `/opt/kde3/share/apps/kdevappwizard/template-kapp/` directory. Just replace `/opt/kde3/` by the &kde; directory on your system.

Questo `script` &perl; è chiamato con una serie di argomenti, contrassegnati dal prefisso `--`, nei quali la procedura guidata ha inserito le informazioni relative alle selezioni fatte nella finestra di dialogo Crea nuovo progetto.

L'esatta serie delle fasi di inizializzazione dipende da quale `script` perl è stato chiamato. Se si vuole controllare, guardare nel file che viene chiamato dal comando perl nella prima linea della finestra Messaggi.

Gli script usano una serie di subroutine in &perl; raccolte nel file `kdevelop.pm` che si può trovare nella sottodirectory `share/apps/kdevwizard/template-common/` della propria installazione &kde;.

##### La directory di base dell'applicazione

Quando viene eseguito lo script &perl;, si riceve una serie di messaggi su cosa sarà fatto nella prossima fase dell'installazione. Dapprima verrà impostata una `directory di destinazione`. Questa è la directory di base della propria applicazione, che era visualizzata nella linea Posizione finale nella pagina Generale della finestra di dialogo Crea nuovo progetto. Lo script usa il valore del parametro `--dest` nel comando suddetto.

##### I file dei modelli

In the next step the file templates you set up in the Create New Project dialog will be copied to the `templates` subdirectory of this destination directory. As you can see from the `--filetemplates` parameter, the templates are submitted in pairs—the suffixes they are used for first, followed by the name of a temporary file in which the &appwizard; has copied the contents of the templates dialog pages. These suffixes will be taken as the filenames of where to store the template texts.

Nel nostro esempio sono installati due modelli, cioè `templates/h` per gli header C++ e `templates/cpp` per i file sorgenti C++.

##### Il file di licenza

Nella pagina Generale della finestra di dialogo Crea nuovo progetto è stata selezionata la licenza con la quale si rilascia la propria applicazione. Da questo, la procedura guidata avvia due operazioni. Una è l'inserimento dell'indicazione della licenza nei modelli. L'altra operazione copia il file di licenza appropriato nella directory di base dell'applicazione.

The `--licensefile` parameter tells the &perl; `script` which license text file to copy. In our example the `/home/devel/projects/myapp/COPYING` file will have been installed in this step.

##### La directory di amministrazione

&kdevelop; necessita di un gruppo di file per amministrare il progetto. Questi sono posti nella sottodirectory `admin` nella propria directory di base dell'applicazione.

In questa fase, la procedura guidata crea la sottodirectory `admin` ed estrae il set standard di file necessari dal pacchetto `share/apps/kdevappwizard/template-common/admin.tar.gz` nella directory &kde;.

&kdevelop; usa sempre lo stesso set di file standard per i propri scopi di amministrazione. Quindi non è necessario nessun parametro nello `script` &perl; per impostare la sottodirectory `admin`.

##### I file dello standard di codifica &gnu;

Ci sono diversi file standard da distribuire con ogni applicazione che è conforme allo standard di codifica &gnu;. Lo `script` &perl; estrae questi file dal pacchetto `share/apps/kdevappwizard/template-common/gnu.tar.gz` dalla propria directory di installazione &kde; e li modifica in modo appropriato in base alle informazioni fornite nella finestra di dialogo Create New Page.

Dopo questa fase nella directory di base dell'applicazione si troveranno i seguenti file:

- `AUTHORS`, contenente inizialmente le informazioni dei parametri `--author` e `--email`.

- `COPYING`, this is the general &gnu; license, which all &gnu; conforming applications must contain—even if you decided to put your application under another license.

- `ChangeLog`, initially empty—you should protocol all major changes here.

- `INSTALL` contains generic installation instructions—modify this if special precautions and/or procedures are needed to install your application.

- `README`, initially empty—put any information here the user should know before installing your application.

- `TODO`, initially empty—put information here about what has to be done to further develop your application. You can use this as a notebook for your own purposes, but it is all the well really helpful once you have put your application in public domain.

##### La documentazione iniziale dell'applicazione

Ogni progetto che viene impostato conterrà un modello iniziale DocBook da dove si può partire per scrivere la documentazione dell'applicazione. Lo script &perl; avrà impostato in questa fase le sottodirectory `doc` e `doc/en` con un modello iniziale `doc/en/index.docbook` e alcuni file `Makefile.am` del gestore automake dai quali &kdevelop; può costruire in seguito i file del sistema di help.

##### Il file di progetto

Up to here most of the more global stuff has been set up, things which more or less are to be found in any &kdevelop; project. With this step the more application-specific setup processes start. These may vary upon the type of application you selected. Have a look at the actual &perl; `script` the &appwizard; called up for your new application if you want to lookup details. We will continue to follow the example steps listed above.

In the first step of these the &kdevelop; project management file is copied out of the template directory, where the &perl; `script` resides. In our case the `share/apps/kdevappwizard/template-kapp/app.kdevelop` file was copied into the application base directory and then customized according to the selections made in the Create New Project dialog.

You may want to have a look at the resulting project file which in our case was saved as `/home/devel/projects/myapp/myapp.kdevelop`. It is written in XML format and easily to be displayed with Kate or any other text editor. But take care nothing to change as &kdevelop; relies on its contents.

##### Il framework dell'applicazione

Ora è il momento di impostare la struttura della directory e gli altri file di manutenzione per metterli nella nuova applicazione. In questa fase verrà impostato un cosiddetto framework dell'applicazione. La sua struttura dipende principalmente dal tipo di applicazione selezionata nella finestra di dialogo Crea nuovo progetto, ma alcune parti sono tanto comuni da essere trovate anche in altri progetti.

In our case the following directory structure has been created in the `/home/devel/projects/myapp/` application base directory:

- La sottodirectory `src` è destinata a contenere i file sorgente dell'applicazione.

- La sottodirectory `debug` conterrà l'output compilato della configurazione debug della compilazione. (Vedere il capitolo Configurazione della compilazione per ulteriori informazioni). Come dice il nome, si dovrebbe usare questa directory per scopi di debug.

- La sottodirectory `optimized` conterrà l'output compilato della configurazione optimized della compilazione. Si dovrebbe testare qui la versione ottimizzata della propria applicazione.

- La sottodirectory `po` è destinata per la traduzione. Conterrà i file Portable Object (file `.po` ) e i modelli (`.pot` files) che saranno elaborati da un programma di traduzione come ad es. KBabel.

All these directories will not kept empty but filled with a series of `Makefile` and other files &kdevelop; uses to process the sources of the application. Also some initial icon files for the new application will have been put into the `src` subdirectory, if applicable. In our case you will find two of them: `src/hi16-app-myapp.png` and `src/hi32-app-myapp.png` which both hold standard &kde; application icons.

##### Installazione dei sorgenti dell'applicazione

Questo framework infine viene usato per inserire i file sorgenti iniziali del nuovo progetto nella directory `src`. I file attuali dipendono strettamentedal tipo di applicazione selezionata nella finestra di dialogo Crea nuovo progetto. Presto si vedrà da soli come queste sono le cose con cui si deve lavorare.

#### Impostare &CVS;

Now let us have a look at what the Messages window will contain when the &appwizard; continues to build our example project. If no error occurred during the first pass, the Messages contents will revert to create the local &cvs; repository.

Come prima le linee di output sono state riformattate per migliorare la leggibilità. Sono state rimosse alcune linee superflue (dove sono presenti i puntini . . .).

    * cd '/home/devel/projects/myapp' \
      && cvs -d '/home/devel/cvsroot' \
             import -m 'new project' \
                    'MyApp' \
                    'vendor' \
                    'start' \
      && sh /opt/kde3/share/apps/kdevcvs/buildcvs.sh . \
                                                     'MyApp' \
                                                     '/home/devel/cvsroot'
      . . .
    * N MyApp/NEWS
    * N MyApp/TODO
    * N MyApp/README
      . . .
    * N MyApp/admin/configure.in.bot.end
    * N MyApp/templates/h
    * N MyApp/templates/cpp
    *
    * No conflicts created by this import
    *
    * *** Success ***

Come si può vedere dalla prima linea la procedura guidata ha costruito una nuova linea dei comandi che guida il lavoro del &cvs;. Dapprima la shell si sposta nella nuova directory di base dell'applicazione per usarla come default nelle fasi seguenti.

##### Costruire il repository &cvs;

Nella seconda linea viene chiamata l'applicazione &CVS; per importare i contenuti del progetto iniziale nel repository desiderato. Nuovamente, l'attività nei dettagli è controllata da una serie di argomenti a linea di comando della chiamata all'applicazione &CVS;

- `-d '/home/devel/cvsroot'`—the `-d` option tells &CVS; which root directory is to be used. In our case this is the local &cvs; root located in `/home/devel/cvsroot`.

- `import`—tells the &CVS; application which operation to perform in this root. We want to import files into the &cvs; database. To accomplish this, the `import` command needs some arguments of its own:

  - `-m 'new project'`—the `-m` option provides import some message text for this action. It will be stored in the database and can later be recalled to identify the data which was kept in this step. In our case `new project` denotes the storage of our first files in the database.

  - `'MyApp'`—the second argument tells &CVS; which repository to use. If it does not exist, it will be created prior to the file import actions. In this case the `MyApp` repository will be created.

  - `'vendor'`—this following argument is a tag, a symbolic name which marks a series of files in the directory. There are several different meanings such a tag can have (see Using CVS for more information), this one in principle marks the whole bunch of files which subsequently will ever be stored in this repository. It is of no particular use to us, so `vendor` is as good a name as any other.

  - `'start'`—is another tag. It marks the release, in easy words a series of subsequently saved files which belong together. We used `start` here, a meaningful description of the use of this initial series.

##### I file importati

The &CVS; application will create the repository and then start to import all files from our `/home/devel/projects/myapp` directory. It subsequently reports any file which is loaded—this is the contents of the whole bunch of `N` lines following in the Messages window. The `N` denotes that this file was newly imported into the repository.

A seconda del tipo della nuova applicazione ci saranno molte linee con `N`. L'output è stato tagliato in modo da mostrare solo le prime e le ultime tre linee come esempio.

##### Messaggio di successo del &CVS;

&CVS; comunica sempre quando una operazione è stata eseguita con successo. Nel nostro caso viene stampato il messaggio `No conflicts created by this import`, seguito dalla linea `*** Success ***` poiché non dove essere compiuta nessun'altra operazione.

Ci potrebbero essere alcuni messaggi di errore su file in conflitto se il repository esisteva già perché &CVS; controlla il contenuto del file secondo alcuni criteri formali e comunica ogni conflitto che viene scoperto.

##### Costruire gli elementi dell'amministrazione &cvs;

The &CVS; import operation is concluded at this point. The repository has been set up and all files we want to be kept were stored in the database. Yet there is more work to do, because the &CVS; application needs some administration information kept in every directory of the application. It uses this information later to communicate with the cvs root and repository.

Se si sta lavorando con &CVS; si deve fornire un sistema per permettere a &CVS; di immagazzinare questa informazione nella directory di lavoro. Ad esempio si può effettuare il check out dei file in una directory di base vuota, nel quale caso &CVS; scriverà automaticamente tutte le operazioni di amministrazione assieme ai file.

In &kdevelop; c'è fortunatamente una via più veloce. Esso fornisce uno script per la shell chiamato `buildcvs.sh` nella directory `/opt/kde3/share/apps/kdevcvs/` (nuovamente, sostituire `/opt/kde` con la propria directory di installazione di &kde;), che viene chiamato dalla procedura guidata dopo che &CVS; ha finito il suo lavoro con successo.

Principalmente lo script `buildcvs.sh` inserisce in ogni directory del framework dell'applicazione una sottodirectory `CVS`. Ognuna di queste sottodirectory contiene i tre file seguenti:

- `Root` contiene il nome del server nel quale è situata la radice &cvs;. Nel nostro caso questa è la radice locale `/home/devel/cvsroot`. Lo scopo principale consiste nel mantenere sempre lo stesso repository per questi file, perché &CVS; non li memorizza interamente, ma registra solo le differenze tra le parti successive. Questo fa risparmiare molto spazio del disco ma rende necessario mantenere unite tutte le informazioni successive in qualunque circostanza.

- `Repository` serves the same purpose. &CVS; keeps the name of the repository to use herein, `MyApp` in our case.

- `Entries` holds the names and some other data about the files &CVS; will care of in this directory. This is because &CVS; does not necessarily keep every application file in the repository. You can tell it which files to store and which to ignore—this information is kept in the `Entries` file.

All these efforts are necessary because &CVS;'s work is directory-oriented. As &CVS; previously had stored all files in the `MyApp` framework, the `buildcvs.sh` script simply scans every directory and puts the names of all application files it finds into the according `CVS/Entries` file.

Lo script viene eseguito silenziosamente, senza che venga mostrata alcuna linea nella finestra Messages.

## Advanced Project Management

### Loading Projects

#### Loading a Recently Used Project

(... to be written ...)

#### Loading an Existing Project

(... to be written ...)

#### Convertire i vecchi file di progetto di KDevelop

&kdevelop; permette di aprire i vecchi file di progetto di KDevelop 2.x e convertirli in file di &kdevelop;. Per fare questo andare su Apri progetto... e selezionare File progetto KDevelop nel campo Filtro:. Poi selezionare il file di progetto che si vuole aprire. Il progetto verrà convertito e salvato come File progetto &kdevelop;.

#### Importing an Existing Project

Per importare una directory esistente in &kdevelop; selezionare Importa progetto esistente dal menu Progetto. Dovrebbe apparire la procedura guidata per importare una directory, come qui sotto:

##### La finestra di dialogo Importa progetto esistente

### Tayloring the Project—Project Options

(... to be written ...)

## Strumenti di editing

### Code Snippets

#### Features (preliminary survey)

- SnippetPart adds a tool-view which by default docs to the right

- Adding, editing and removing of snippets is available via a popup-menu

- Double-clicking a snippet form the list inserts it into to the active view at the current cursor position

- Tool tips show the content of a snippet

- Snippets are stored in the users home-directory, so every user can have his own snippets

- Snippets can contain variables in the style of $VARNAME$. On using the snippet the user is prompted to enter replacement value for the variables

### Tasti Speciali

Di seguito verranno elencate le scorciatoie dell'editor di default. Possono essere configurate a piacimento.

Sinistra | Si muove di un carattere a sinistra
Destra | Si muove di un carattere a destra
Ctrl Sinistra | Si muove di una parola a sinistra
Ctrl Destra | Si muove di una parola a destra
Su | Si muove in alto di una linea
Giù | Si muove in basso di una linea
PgUp | Si muove in alto di una pagina
PgDn | Si muove in basso di una pagina
Ctrl PgUp | Si muove all'inizio del file
Ctrl PgDn | Si muove alla fine del file
Home | Si muove all'inizio della linea
Fine | Si muove alla fine della linea

Per tutti le combinazioni sopra elencate, può essere premuto in aggiunta il tasto Shift per selezionare dalla posizione attuale a quella seguente.

Backspace | Cancella il carattere a sinistra
Canc | Cancella il carattere sotto al cursore
Ctrl C | Copia il testo selezionato negli appunti
Ctrl V | Incolla il testo selezionato negli appunti
Ctrl X | Cancella il testo selezionato e lo mette negli appunti
Ctrl Z | Annulla
Shift Ctrl Z | Ripete

### Reporter di problema

(... to be written ...)

### Cercare e usare grep

#### Cercare il testo

Ctrl F- TrovaCtrl R- Sostituisci

#### ISearch

La ricerca tradizionale con il comando Modifica Trova richiede di specificare l'intero termine da cercare prima di avviare la ricerca. Spesso è molto più veloce cercare in modo incrementale. Se si clicca nel campo chiamato ISearch nella barra degli strumenti, la ricerca verrà effettuata mentre si digita. Spesso il termine desiderato viene trovato dopo aver scritto 3 o 4 lettere.

#### Grep

Entrambi i meccanismi di ricerca descritti prima sono limitati all'interno di un file sorgente. Attraverso la voce Cerca nei file... nel menu Modifica è disponibile uno strumento aggiuntivo che permette di cercare attraverso un insieme (anche grande) di file. Fondamentalmente è un frontend per il programma &grep;(1).

In the dialog, you can specify which files are searched. There is a number of wildcard patterns available in a combobox. 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.

Generalmente il termine da cercare è un'espressione regolare che segue la sintassi POSIX. Per esempio, si può usare il termine `"\<K.*"` se si vogliono trovare tutte le parole che iniziano con la lettera K. I seguenti caratteri sono interpretati in maniera speciale:

`.` | Corrisponde ad ogni carattere
`^` | Corrisponde all'inizio di una linea
`$` | Corrisponde alla fine di una linea
`\<` | Corrisponde all'inizio di una parola
`\>` | Corrisponde alla fine di una parola
`?` | L'elemento precedente corrisponde meno di una volta
`*` | L'elemento precedente corrisponde zero o più volte
`+` | L'elemento precedente corrisponde una o più volte
`{n}` | L'elemento precedente corrisponde esattamente n volte
`{n,}` | L'elemento precedente n o più volte
`{,n}` | L'elemento precedente corrisponde meno di n volte
`{n,m}` | L'elemento precedente corrisponde almeno `n` volte ma meno di `m` volte

I riferimenti alle espressioni tra parentesi sono disponibili tramite la notazione `\n`.

In aggiunta per i programmatori C++ ci sono alcuni modelli di ricerca tipici. Questi permettono ad esempio di cercare tutte le chiamate a funzioni membro di un certo oggetto.

Quando si avvia una ricerca cliccando sul pulsante Cerca, essa verrà effettuata da un processo asincrono esterno. Tutti gli elementi trovati appariranno nella visuale chiamata Grep. Si può saltare direttamente all'elemento trovato cliccando su di esso. Notare che grep scansiona i file come sono memorizzati nel file system. Se si hanno versioni modificate di questi file nel proprio editor si potrebbero ricevere errori nel numero di linea o alcuni elementi potrebbero non essere validi. Si possono evitare questi problemi salvando anticipatamente tutti i file.

### Completamento del codice

(... to be written ...)

### Creare nuovi File e Classi

(... to be written ...)

#### Modificare i modelli

(... to be written ...)

## Il browser di file

&kdevelop; può visualizzare diversi tipi di liste ed alberi per la selezione dei file nella parte sinistra della finestra principale:

- ### Albero dei file

  Questo mostra una vista ad albero della gerarchia di file al di sotto della directory del progetto. Se si clicca su un file verrà caricato nell'editor. Per i file che non contengono testo KDevelop avvierà un'applicazione che può gestire il tipo MIME corrispondente.

  L'albero dei file viene aggiornato regolarmente ogni volta che cambia qualcosa nel file system. Per esempio, se si creano nuovi file o directory (anche fuori da &kdevelop;), il cambiamento si riflette immediatamente nella lista dei file. Su Linux, questa caratteristica utilizza la libreria FAM. Su altri sistemi operativi o su NFS le directory visualizzate sono controllate periodicamente a brevi intervalli.

  L'albero dei file nasconde i file che normalmente non sono interessanti, come i file oggetto. In Project options del menu File views si possono configurare (come elenco di caratteri jolly separati da virgola) quali pattern devono essere usati per filtrare i file irrilevanti.

  Inoltre si può decidere di limitare l'albero dei file per visualizzare solo i file che appartengono al progetto corrente. Questa modalità può essere cambiata cliccando con il tasto destro del mouse sull'elemento radice dell'albero.

  ### Uno screenshot dell'albero dei file

- ### Gruppi di file

  Questo visualizza i file che appartengono al progetto, raggruppati per estensione. Come nell'albero di file, si può modificare un file cliccandolo con il tasto sinistro del mouse.

  I gruppi mostrati in questa visualizzazione possono essere configurati con Gruppi di file nella finestra di dialogo Opzioni progetto.... Per adattare la visualizzazione alle proprie esigenze, è utile capire come i file vengono distribuiti nei gruppi. Per ogni file &kdevelop; attraversa tutti i gruppi dall'alto al basso. Per ogni gruppo viene controllato se il file corrisponde a uno schema. Se viene trovata una corrispondenza il file viene visualizzato in quel gruppo e viene interrotta l'iterazione. Questo spiega perché gli schemi più generali dovrebbero essere messi al di sotto di quelli più specifici. Per esempio l'ultimo schema dovrebbe essere un asterisco per il gruppo Altro.

## Il browser delle classi

Quando si lavora ad un progetto con un linguaggio orientato agli oggetti, l'attenzione non è concentrata sui file sorgente e sui loro nomi, ma sulle classi e le loro relazioni. Per aiutare a navigare lo spazio delle classi e dei simboli definiti, &kdevelop; include vari browser delle classi che visualizzano la struttura delle classi in varie modalità.

### Visuale delle classi

Questa visuale è mostrata nella parte sinistra della finestra principale e contiene un elenco lineare di tutte le classi, variabili e funzioni del progetto. È organizzata come una visuale ad albero. Se si apre il nodo di una classe cliccandoci sopra viene visualizzata una lista di tutti i metodi e gli attributi di quella classe.

#### Uno screenshot della visuale delle classi

La visuale delle classi funziona in due modalità differenti. Per default tutti i simboli sono raggruppati in classi, strutture, funzioni, variabili e namespace. Nel menu contestuale si può scegliere List by Namespaces. In questa modalità viene visualizzata la gerarchia dei namespace, con i simboli raggruppati nel namespace dove sono definiti. Può essere utile nei progetti che fanno grande uso di namespace, mentre è meno utile in progetti che non li usano.

Si può anche cambiare il modo con cui vengono visualizzati i nomi delle classi. Normalmente sono mostrati i nomi delle classi senza il namespace in cui sono definite. Questo implica che non si può distinguere immediatamente le classi con lo stesso nome definite in namespace diversi. Se si rimane con il mouse per un po' sopra ad un elemento viene mostrato un tooltip con l'intero percorso del nome. Si può decidere di visualizzare sempre il nome completo scegliendo Full Identifier scopes dal menu contestuale.

Cliccando su una classe o su un metodo viene mostrata la definizione. Si può anche saltare alla dichiarazione di un metodo scegliendo Vai alla dichiarazione dal menu contestuale. In questo menu sono presenti anche le voci Aggiungi metodo.. e Aggiungi attributo.... Queste aprono delle finestre di dialogo dove si possono generare nuove dichiarazioni di metodi e variabili, senza implementazione.

### Strumenti per le classi

La finestra di dialogo class tool è attivata cliccando una classe con il tasto destro nella visuale delle classi e scegliendo Class tool....

### Gerarchia delle classi

(... to be written ...)

## Documentazione

Sfortunatamente la documentazione fa parte delle questioni più trascurate. Tuttavia una volta impostata e mantenuta, la documentazione interna ed esterna fornisce un'aiuto molto importante.

La documentazione possiede diversi aspetti. C'è

- documentazione interna al progetto, che consiste principalmente in

  - commenti nei file header/sorgente

  - documentazione API interna del proprio progetto generata da strumenti speciali come ad esempio &doxygen;

- documentazione esterna del progetto che comprende

  - documentazione API esterna ad es. di librerie di sistema (KDE, Qt, ecc.)

  - ogni altra documentazione (manuali di programmazione, informazioni generali di sistema, articoli HowTo e simili)

Tutta questa documentazione dovrebbe essere manutenibile e a portata di mano ogni volta che serve. &kdevelop; ha la soluzione proprio per questo.

### Il browser della documentazione

#### Uno screenshot dell'albero della documentazione

## Compilazione e gestione del progetto

Questo capitolo si occupa solo di progetti compilati, come C++, Java o Fortran. I progetti per linguaggi di scripting come Python e Php funzionano in modo molto diverso.

Si troveranno informazioni sui seguenti argomenti:

- Summary of &automanag; containing an initial overall view of &automanag;,

- Automake Manager Operation describing the basics of how to work with &automanag;,

### Sommario sul gestore Automake

In the Build systems chapter we have given a rough survey of the build systems commonly in use on UNIX systems. In the following sections we will look at this in more detail.

È presente una certa confusione su come chiamare queste cose. GNU parla di sistemi di compilazione (build systems) quando descrive Automake, Autoconf e Libtool. QMake si descrive come uno strumento per scrivere Makefile per diversi compilatori e piattaforme. In KDE è spesso usato il termine sistemi di estione di progetti (project management systems). Si userà questo permine in senso più ampio per descrivere l'ambiente incorporato di &kdevelop; che è usato per organizzare e compilare i progetti. Nel contesto di questa sezione, comunque si parlerà principalmente di sistemi di compilazione automatici.

#### Il necessario per un sistema di compilazione automatico

Se si ha un semplice programma Hello World scritto in C, lo si può compilare ed effettuare il linking usando il comando `gcc` `-o hello hello.c` e può essere eseguito usando il comando `./hello`, perciò non è addirittura necessario un `Makefile`.

Se si ha un'applicazione C con diversi moduli e file header che viene eseguita solo sulla propria macchina (cioè un'applicazione "interna"), servirà solo un semplice `Makefile`, che è abbastanza semplice da scrivere a mano (per maggiori informazioni consultare `info Make`).

Le complicazioni iniziano quando:

- Il codice sorgente, la documentazione, la grafica, i suoni, le traduzioni, i file di dati, ecc. sono presenti in più di una directory,

- Si ha una gerarchia di directory e sottodirectory,

- Si stanno usando librerie che non fanno parte dell'insieme tradizionale presente in &UNIX;, come le librerie &Qt; o le librerie &kde;,

- Si sta usando un pre-processore per gererare parte del codice sorgente, come il pre-compilatore MOC di Qt,

- Si vuole distribuire l'applicazione a livello mondiale, a persone che potrebbero non avere lo stesso sistema &UNIX;/&Linux; o lo stesso software e hardware,

- Si necessita di un sistema di installazione e disinstallazione,

- Si vuole far sì che l'applicazione faccia parte di &kde; Desktop.

If you have some or all of the above situations, you probably need a build system. In the example above we used `gcc` to compile and build the Hello World program, but not all C compilers are called `gcc`. So if you distribute your application to someone who is using some other C compiler, your Makefile must somehow use the name of that person's compiler, otherwise your application will fail to compile—and that is just simple example of what can go wrong.

Un sistema di compilazione nasconderà queste differenze.

- Controllerà che le librerie necessarie siano presenti su ogni macchina di destinazione,

- scansionerà automaticamente tutte le directory dell'applicazione per cercare i file da pre-processare, compilare o installare e

- installerà i componenti dell'applicazione nelle directory di destinazione corrette, assicurandosi che

- le directory vengano create come richiesto sulla macchina di destinazione.

In brief, a build system offers safe and secure methods for your application to be compiled and installed correctly on any receiving machine. As we have shown before in the Project Management Systems survey, &kdevelop; offers three automated build systems and the option of creating your own Makefile, in short (click on the project names to get more information):

- I Progetti Automake che usano gli strumenti standard di sviluppo &gnu;.

- I Progetti QMake che usano il gestore di progetti Qmake di Trolltech.

- I Progetti ANT che usano il gestore di progetti ANT di Apache per lo sviluppo con Java.

- I Progetti personalizzati che richiedono che si gestiscano i propri `Makefile`.

Quando si crea un progetto si deve sceglierre una di queste quattro alternative e questa scelta è difficile da cambiare in seguito, quindi ci si dovrebbe pensare un momento prima di iniziare.

#### Tutorial su Autoconf/Automake/Libtool

Esistono diversi tutorial disponibili sul sistema di compilazione &GNU; usato dal Gestore Automake (`Autoconf`, `Automake` e `Libtool`).

- Un breve tutorial su autoconf scritto da Christopher W. Curtis è disponibile sulla home page di KDevelop. Esso illustra in pochi passi le istruzioni su come modificare un `Makefile`.

- A more detailed tutorial can be found in a greater set of tutorials on Developing software with GNU.

- And there is the famous Goat Book, titled Autoconf, Automake, and Libtool. This is an easily readable, yet concise, introduction in all main aspects of the &GNU; Autotools.

#### Cosa fa il Gestore Automake?

Quando si crea un Nuovo progetto che usa il sistema di compilazione &GNU;, come C++ KDE Application Framework, la procedura guidata imposta i primi file `Makefile.am`.

There will be one `Makefile.am` file in each directory of your project that contains files to be compiled or installed. It will contain your specifications for compiling, building and installing files and a reference to any subdirectories that also have a `Makefile.am` file and possibly some files to compile, build and install.

La directory del progetto e i file sorgente possono essere strutturati a qualunque livello di profondità, oppure si può preferire una struttura piatta con tutte le sottodirectory al livello più alto.

Lo scopo del sistema di compilazione &GNU; consiste nel produrre strutture di file sorgenti che possano essere compilati e installati su ogni sistema &UNIX; o &Linux; usando questi semplici comandi:

    ./configure
    make
    make install    # Normalmente come "root".

e possano essere disinstallati dal comando `make uninstall` (normalmente come utente root).

Come funziona? `configure` è uno script che

- risolve le problematiche relative ai dettagli del sistema in cui si trova, come quale compilatore e librerie usare e dove sono localizzate e in seguito

- crea file `Makefile` ricorsivi completando le sostituizioni nei corrispondenti file `Makefile.in`.

The `Makefile.in` are input files—templates which provide basic information for the `Makefile`s to be produced from them by filling in some system dependent information. They are generated by the `Automake` utility from the `Makefile.am` files.

Il processo che parte dai `Makefile.am` (`.am` significa file modello di Automake) fino ad arrivare ai file `Makefile` viene gestito automaticamente dal &promanag; di KDevelop, usando l'utility `Autoconf`, le macro `M4` e altre cose arcane in cui non è necessario addentrarsi.

In questo modo, quando viene avviato `make`, esso ottiene automaticamente le parti corrette dal sistema, come compilatori e librerie. Analogamente, `make install` mette i componenti dell'applicazione, come i file eseguibili, la documentazione e i file di dati nei posti corretti per quell'ambiente.

Se si distribuisce l'applicazione come tarball (un singolo file compresso che può essere creato da KDevelop), esso includerà i file `Makefile.in` e il file script `configure`, in modo che il destinatario potrà compilare e installare l'applicazione senza possedere sul proprio computer `Automake`, `Autoconf` o KDevelop. Vengono inclusi anche i file `Makefile.am`, nel caso in cui il destinatario debba fare qualche modifica al codice sorgente.

Le regole sono piuttosto diverse se si distribuisce attraverso un repository di codice sorgente come il CVS di KDE.

#### Riassunto delle funzioni del Gestore Automake

- Genera i file `Makefile.am` nelle sottodirectory conosciute come sottoprogetti.

- Aggiorna i file `Makefile.am` quando cambia la struttura del progetto.

- Aggiorna i file `Makefile.am` quando vengono aggiunti o rimossi dei file dal progetto.

- Interpreta le definizioni sulla compilazione e installazione dei vari file e modifica adeguatamente i file `Makefile.am`.

- Accetta i parametri usati nella compilazione o installazione (ad es. i nomi di libreria) e si assicura che siano usati nelle fasi di compilazione.

#### Contenuti dei file Automake

Le linee di un file `Makefile.am` contengono nomi di variabile seguiti dal segno di uguale e una lista di file o valori di parametri. Le variabili hanno nomi costituiti da due parti, come `bin_PROGRAMS`, `myapp_SOURCES` o `kdelnk_DATA`. La seconda parte è detta primaria e rappresenta qualcosa da compilare o installare. La prima parte è chiamata il prefisso e rappresenta:

- Una directory nella quale effettuare l'installazione (ad es. `bin`),

- Un qualificatore per la parte primaria (ad es. `myapp` per `SOURCES`, indicando che i file sorgente elencati dopo `myapp_SOURCES` finiranno nella compilazione di `myapp`),

- Lo speciale prefisso `noinst` (abbreviazione per nessuna installazione), normalmente usato per elencare i file header (`.h`),

- O lo speciale prefisso `EXTRA`, per tutte le cose dipendenti dalla configurazione.

Per ulteriori informazioni sui file `Automake` e `Makefile.am`, controllare `info Automake`.

Fondalmentalmente il gestore Automake crea e aggiorna i nomi delle variabili e le liste di file o parametri. Vedere il seguente esempio di un `Makefile.am` per una applicazione tipica chiamata `myapp`.

    ## Makefile.am for myapp

    # this is the program that gets installed.  it's name is used for all
    # of the other Makefile.am variables
    bin_PROGRAMS = myapp

    # set the include path for X, qt and KDE
    INCLUDES = $(all_includes)

    # the library search path.
    myapp_LDFLAGS = $(KDE_RPATH) $(all_libraries)

    # the libraries to link against.
    myapp_LDADD   = $(LIB_KFILE) $(LIB_KDEPRINT)

    # which sources should be compiled for myapp
    myapp_SOURCES = main.cpp myapp.cpp myappview.cpp

    # these are the headers for your project
    noinst_HEADERS = myapp.h myappview.h

    # let automoc handle all of the meta source files (moc)
    METASOURCES = AUTO

    KDE_ICON = myapp

    # this is where the kdelnk file will go
    kdelnkdir = $(kde_appsdir)/Utilities
    kdelnk_DATA = myapp.desktop

    # this is where the XML-GUI resource file goes
    rcdir = $(kde_datadir)/myapp
    rc_DATA = myappui.rc

    AM_CXXFLAGS = -DMY_C++_PREPROCESSOR_OPTION

As you can see, many of the items on the right hand side are symbols of the form `$(xxx)`. These are environment variables which are defined in the actual &kde; environment and are substituted with real values when `./configure` generates the final `Makefile` files in the receiving machine.

Inoltre, dopo aver iniziato a usare Kdevelop (FIX) è una buona idea avviare il comando `./configure -help` che visualizzerà tuuto ciò che si può cambiare al momento della compilazione, ad esempio per un test dell'ambiente. In particolare, il comando:

    ./configure --prefix=/dove/si/desidera

direzionerà l'intera installazione in una struttura di directory a scelta, cambiando il valore della variabile interna `$(prefix)` in `/dove/si/desidera`.

### Operazioni del gestore Automake

In questo capitolo si troverà una descrizione essenziale degli elementi del gestore Automake e sul loro uso. Questo comprende:

- The &automanag; Window describes the basic structure of the &automanag; main window.

- The Overall View Window describes the elements of the upper subwindow.

- The Detail View Window describes the elements of the lower subwindow.

- Navigating in the &automanag; lists some basic operations you can perform in the &automanag;.

- Popup Menus in the &automanag; describes the windows which will pop up when you select an action in the &automanag;.

#### La finestra del gestore Automake

- &automanag; runs in a split window. The top part is called the Overall View and the bottom part is called the Detail View. Between them is a narrow bar that can be dragged with the mouse to adjust the sizes of the views. In IDEAl mode you can also drag the side of the split window to change the width.

- Nella parte alta di entrambe le visuali c'è una barra degli strumenti, nella quale i pulsanti vengono attivati quando siseleziona un elemento in quella visuale. Questo fornisce un modo per accedere alle azioni disponibili per quell'elemento. Gli altri sono menu contestuali che appaiono con il click del tasto destro del mouse, come verrà spegato dopo.

- In IDEAl mode there are two additional small buttons in the &automanag; window titlebar left hand side – a triangular shaped right arrow, and a dot button. The arrow button is used to close the window. The dot button on the other hand will keep the window open even if another &kdevelop; window has been selected. (Otherwise the &automanag; window will automatically close whenever another window gets the input focus.)

#### The Overall View Window

The overall view window contains a tree-list of all the directories in your project that contain program files, documentation or data. Each such directory contains a `Makefile.am` file and is known in &automanag; as a subproject. There are three typical subprojects in a &kde;-based project as shown in the above illustration:

- `src` – file sorgente dell'applicazione.

- `doc` – manuale utente o guida,

- `po` – estratti delle stringhe dei file sorgente che devono essere tradotte in altri linguaggi umani (ad esempio titoli delle finestre, nomi di menu, etichette dei pulsanti, testi delle finestre di dialogo e messaggi di vario tipo).

Notare che il sottoprogetto `doc` ha sempre un sottoprogetto `en`, che si può vedere se si clicca sul simbolo + vicino alla parola `doc`. Questo è dovuto al fatto che il linguaggio di base di tutta la documentazione KDE è l'inglese (en). Se la propria applicazione farà parte di KDE, i team di traduzione potranno tradurre la documentazione dall'inglese in altri linguaggi e le traduzioni andranno negli altri sottoprogetti, come `de` (Tedesco) o `fr` (Francese). Anche le stringhe nel sottoprogetto `po` potranno essere tradotte e memorizzate negli altri file in `po`, consentendo quindi all'applicazione di essere utilizzata dalle persone che non conoscono l'inglese.

I sottoprogetti `doc` e `po` servono a diversi scopi. `doc` contiene la documentazione come il manuale utente, `po` contiene le stringhe di testo traducibili dell'interfaccia utente che è integrata nel codice sorgente dell'applicazione.

The overall view window serves—amongst other things—as a navigation tool. If you select a subproject in the overall view window, the corresponding details will be shown in the detail view window.

#### la finestra dettagli

The detail view contains a tree-list of all the files in the subproject currently selected in the overall view as well as the compilation, build and installation rules for this subproject. Thus the two views together can give you access to all the components of your application and all the information on how to compile, build and install it.

##### Target

The tree-list in the detail view has two levels. The top level consists of so-called &automanag; targets and the next level contains lists of files that go to make up each target.

Il concetto di target differisce da quello dei target dei file `Makefile`. In breve:

- Il modo in cui deve essere compilato o installato un insieme di file è chiamato target nel Gestore Automake, mentre viene rappresentato come variabile nello stesso `Automake`.

- In `make` un target è spesso qualcosa di completamente differente, essendo il parametro di un comando `make` (ad es. `make install`, `make clean`).

  Comunque, alcune variabili di `Makefile.am` rappresentano un sub-target in `make`.

#### Navigare nel gestore Automake

In both the overall and the detail view you can left-click on the + or - next to a subproject or target name to expand or contract the tree view. If you do that with a subproject in the overall view, it shows or hides the subprojects at the next level down (if any). If you do it with a target in the detail view, it shows or hides the list of files that go into that target.

##### Aprire un file per la modifica

If you left-click on a file name in the detail view, the corresponding file opens up in KDevelop's editing window.

##### Attivare i pulsanti della barra degli strumenti del gestore Automake

If you left-click on the name of a subproject in the overall view or target in the detail view, the name is highlighted and some toolbar buttons become active in the top part of that view.

È raccomandato l'uso del pulsante destro del mouse e dei menu a comparsa al posto dei pulsanti della barra degli strumenti, poiché risulta più semplice vedere e capire quello che si sta facendo.

Le operazioni sui sottoprogetti e sui target hanno effetti molto estesi sulla struttura, la compilazione e l'installazione dell'applicazione.

##### Selezionare Azioni/Menu a comparsa

Se si clicca con il tasto destro del mouse sul nome di un sottoprogetto, target o file apparirà un menu a comparsa con il quale si potranno selezionare le azioni da eseguire su un sottoprogetto, target o file, come aggiungere un target ad un sottoprogetto, aggiungere un file ad un taget o rimuovere logicamente il file selezionato dal suo target.

#### Menu a comparsa nel gestore Automake

The following sections explain in short terms which operations the menus make available which will pop up on right mouse button clicks in the &automanag; window. They are meant for overall view only. You will find detailed descriptions of most operations in a later chapter.

##### Menu a comparsa per un file

When you right-click on a file name in the detail view the following menu will pop up allowing you to select one of several operations to be performed on that file. In the illustration below the `hi-16app-myapp.png` icon file was selected from the Icon data in myapp target of the myapp/src subproject.

- La voce principale del menu a comparsa per un file è Rimuovi, che rimuove un file dal suo target (cioè non verrà più usato per compilare, costruire o installare quel target).

- La voce CVS fornisce una serie di operazioni CVS per quel file.

- La voce Apri con permette di aprire il file con diversi editor o applicazioni (ad es. si può aprire il file icona dell'esempio con KIcon).

- La voce Perforce è usata in operazioni simili a quelle del CVS, usando il version control system commerciale Perforce.

##### Il menu a comparsa di un target

When you right-click on a target in the detail view the following menu will pop up allowing you to select one of several operations to be performed on it. In the illustration below the myapp (Program in bin) target of the myapp/src subproject was selected.

- La voce Opzioni per un target riguarda solo i file sorgente. Nella finestra di dialogo corrispondente si può specificare i flag del linker, i percorsi per localizzare le librerie e si può fornire una lista di librerie con cui effettuare il link nell'applicazione.

- La voce Crea nuovo file mostrerà una finestra di dilaogo nella quale si potrà impostare il nome e il tipo di file che sarà generato (da una lista).

- La voce Aggiungi file esistenti visualizza una finestra di dialogo nella quale si può aggiungere al progetto dei file esistenti.

- La voce Rimuovi per un target permette di rimuovere logicamente un target e tutti i suoi file dalla struttura del progetto.

- La voce Rendi target attivo si riguarda solo i target che contengono codice sorgente. I nuovi file verranno sempre aggiunti ad un target attivo.

- La voce Compila target avvia tutte le operazioni di compilazione per costruire il codice solo di questo target.

##### Il menu a comparsa per un sottoprogetto.

When you right-click on a subproject in the overall view window the following menu will pop up which allows you to make major changes to the structure of your project and the way it is compiled, built and installed. You can use it to expand or modify the basic project structure that the &appwizard; has created.

- La voce Opzioni controlla il modo in cui un sottoprogetto verrà compilato, costruito e installato. La finestra di dialogo che appare possiede le etichette per le opzioni che riguardano la compilazione, le directory include, i prefissi e l'ordine di costruzione.

- La voce Aggiungi sottoprogetto crea una nuova directory e lo scheletro di un file Makefile.am.

- La voce Aggiungi Target fa comparire una finestra di dialogo con la quale si possono impostare le regole per la compilazione, la costruzione o l'installazione di un gruppo di file all'interno del sottoprogetto.

- Aggiungi servizio (... da scrivere ...)

- Aggiungi Applicazione (... da scrivere ...)

- Aggiungi sottoprogetti esistenti (... da scrivere ...)

- Il modo appropriato per rimuovere un sottoprogetto consiste nell'uso della voce Elimina sottoprogetto del menu a comparsa del un sottoprogetto. Verranno corretti i file `Makefile.am`. Sarà mostrata l'opzione di concellare si tutti i file (o collegamenti) della directory corrispondente. Ovviamente, questa caratteristica dovrebbe essere usata con cautela.

- La voce Compila avvia le operazioni necessarie per compilare solo il codice di quel sottoprogetto.

- Forza Reedit (... da scrivere ...)

- Ripulisci (... da scrivere ...)

- Installa (... da scrivere ...)

- Installa (come superutente) (... da scrivere ...)

### Progetti automake

(... to be written ...)

#### Autoconf

##### Effetti dello script configure

da `Makefile.in` a `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++

da `config.h.in` a `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

(... to be written ...)

#### Gestore Automake di KDevelop

##### Uno screenshot del gestore automake

#### Compilare e installare librerie

- -rpath

- PIC

- static

- plugins: no-undefined

### Makefile e script di compilazione personalizzati

(... to be written ...)

### Opzioni del compilatore

(... to be written ...)

### Opzioni Make

(... to be written ...)

## Advanced Project Management

### Configurazioni di compilazione multiple

(... to be written ...)

### Cross compilazione

Quando si hanno a disposizione dei cross compilatori si possono compilare i programmi per diversi processori e diversi sistemi operativi da quelli usati dove viene eseguito il compilatore e &kdevelop;. Il &gnu; compiler collection GCC può essere configurato e compilato come un cross compilatore. Consultare le pagine info di GCC per maggiori informazioni. Alcune distribuzioni Linux forniscono anche pacchetti binari.

Un pacchetto basato su automake può essere facilmente cross compilato passando l'opzione `--host` allo script configure e impostando le variabili d'ambiente `CC` e `CXX` sui file binari relativi dei cross compilatori. Spesso si desidera passare dalla versione cross compilata a quella compilata per il proprio sistema e viceversa. Per questo motivo è conveniente usare la capacità di &kdevelop; di creare configurazioni multiple di compilazione, come spiegato . Una volta creata una nuova configurazione di compilazione per la cross compilazione nella finestra di dialogo Progetto Opzioni progetto..., aggiungere l'opzione

    --host=piattaforma

alle opzioni di configure. Il nome piattaforma è una ennupla nella forma

    cpu-vendor-os

o

    cpu-vendor-kernel-os

Si può usare la forma breve per molte combinazioni, per esempio i386-linux o arm-elf.

### Qt/Embedded

&qte; è una versione delle librerie &qt; che non usa il sistema X window, ma nei sistemi Linux disegna direttamente sul framebuffer. Perciò è interessante per sistemi embedded che hanno strette restrizioni sull'uso della memoria di sistema. Le API sono pienamente compatibili con quelle della versione X11.

Sviluppare applicazioni per &qte; con &kdevelop; non è molto diverso dallo sviluppo di un programma per la versione X11 di &qt;. Di fatto, si può usare lo stesso codice per entrambe le versioni. Se si usa il gestore di progetti autoproject si può passare alla versione embedded passando allo script configure l'argomento `--enable-embedded`. Si può impostare questo in Opzioni di configurazione nella finestra di dialogo Progetto Opzioni progetto.... Con l'opzione `--with-qt-dir=DIR` si può impostare la directory in cui è installata la libreria &qte;

Dopo aver configurato e compilato la propria applicazione con queste opzioni, verrà eseguito il link con la libreria `libqpe.so`. Questa versione dell'applicazione normalmente non funzionerà quando si usa X11. Per testarla avviarla sotto il controllo dell'applicazione qvfb (Qt Virtual Frame Buffer). Questo viene fatto avviando qvfb e eseguendo l'applicazione con

    app -qws -display QVFb:0

Naturalmente si vorrà usare una versione funzionante della propria applicazione sul processore di destinazione. Probabilmente sarà utile creare configurazioni multiple di compilazione, come spiegato prima, in modo da passare velocemente tra la versione eseguita nel proprio sistema di sviluppo e la versione eseguita sul sistema di distinazione.

Normalmente le applicazioni per &qte; vengono eseguite come applicazioni singole nei dispositivi per i quali sono state progettate. Trolltech supporta anche Qtopia, che è una collezione di applicazioni per PIM, come browser e altri che funzionano assieme in maniera consistente. Ad esempio è un ambiente standard dello Sharp Zaurus. Si possono scrivere applicazioni che si integrano in questo ambiente usando l'SDK di Qtopia. Questo significa rendere la classe della propria applicazione una sottoclasse di `QPEApplication` ed effettuare il link alle librerie `libqpe.so`. Se si sviluppa l'applicazione con il gestore di progetti autoproject si deve aggiungere `--enable-qtopia` agli argomenti per configure.

## L'interfaccia del debugger

Per i linguaggi C e C++, &kdevelop; contiene un debugger interno che è direttamente integrato nell'editor. Tecnicamente è implementato come un frontend che usa gdb (portable &gnu; debugger) attraverso una pipe. Il debugger può essere avviato in diversi modi:

- Con Debug Avvia,viene caricato dentro il debugger il programma principale del proprio progetto.

- Usando Debug Esamina il file core viene caricato in memoria un file core che è stato generato dal kernel del sistema operativo quando il programma è andato in crash (la generazione di file core potrebbe essere disattivata sul proprio sistema, vedere ulimit(1)). Questo è utile per un'analisi post-mortem del programma.

- Con Debug Allega al processo si usa il debugger su un programma già in esecuzione. Verrà mostrata una lista di processi da dove si può selezionare quello che dovrà essere supervisionato dal debugger.

- Notare che questo debug è possibile se il proprio progetto è stato compilato con l'attivazione delle informazioni di debug. Possono essere attivate nella finestra di dialogo Compiler options. Quando questa opzione è attivata il compilatore genera dati aggiuntivi che permettono al debugger di associare i nomi dei file e numeri di linea con gli indirizzi nel file eseguibile.

Il frontend del debugger fornisce diverse visuali nel processo:

- ### Variabili

  Questa finestra elenca i valori di tutte le variabili locali del punto corrente dell'esecuzione del programma. Esso include le variabili dell'intero stack delle chiamate, cioè la funzione dove è stato interrotto il processo, la funzione che ha chiamato quella funzione e così via fino a `main()`.

  Un altro ramo di variabili contiene le variabili di osservazione. Si possono configurare quali variabili mostrare qui. Possono essere osservate sia le variabili locali che globali. Si possono aggiungere variabili cliccando sul pulsante Aggiungi o premendo RETURN mentre è selezionata la voce Espressione da controllare. Possono essere rimosse nuovamente attraverso il menu contestuale.

- ### Breakpoint

  (... to be written ...)

- ### Stack del frame

  (... to be written ...)

- ### Disassemblare

  (... to be written ...)

### Impostare i breakpoint

(... to be written ...)

### Opzioni

#### Visualizzare nomi mangled (storpiati)

Nel C++, i nomi delle funzioni negli eseguibili sono detti mangled (storpiati), cioè il nome della funzione include le informazioni sul tipo degli argomenti. Questo è necessario per il supporto al sovraccaricamento delle funzioni. L'algoritmo di mangling non è standardizzato e differisce persino tra versioni diverse del compilatore C++ &gnu;

Normalmente nella finestra di disassemblaggio vengono visualizzati nomi non mangled, quindi le firme delle funzioni sono simili a come appaiono nel codice sorgente, quindi facilmente leggibili. In alternativa si può decidere di vedere i nomi mangled.

#### Tentare di impostare i breakpoint al caricamento delle librerie

Il backend del debugger gdb non permette di inserire breakpoint all'interno di codice non caricato. Questo potrebbe essere sconveniente in una applicazione altamente modulare, dove spesso il codice viene caricato su richiesta come un plugin (usando la funzione di libc `dlopen(3)`). Quindi &kdevelop; estende il proprio supporto per i breakpoint nelle librerie condivise. Se si imposta questa opzione si potranno impostare i breakpoint in librerie che non sono state caricate. Quando gdb notificherà che una libreria è stata caricata, &kdevelop; tenterà di impostare i breakpoint sospesi.

#### Abilitare la barra degli strumenti fluttuante

(... to be written ...)

## Usare CVS

### Fondamenti di &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.

Quando uno sviluppatore ha finito un compito, effettua il commit del suo codice (accompagnato da un messaggio di log). &CVS; si occupa della fusione dei cambiamenti fatti dai diversi sviluppatori. Ovviamente può succedere che più sviluppatori lavorino sullo stesso pezzo di codice; potrebbe risultare una serie di cambiamenti in conflitto tra loro (in pratica questo accade raramente, ed è spesso un segno di una carenza di comunicazione). In questo caso &CVS; rifiuta le modifica; si potrà fare il commit di un file solo dopo che saranno risolti tutti i conflitti.

Finora si sono descritte le caratteristiche di base di &CVS; che si possono incontrare. Ma &CVS; ne fornisce molte di più: si possono mantenere diversi rami di un progetto (ad es. &kde; 1.1.2 e &kde; 2 erano rami dell'albero di sviluppo di &kde;), fondere cambiamenti da un ramo all'altro, chiedere le differenze tra le revisioni, la storia delle revisioni di file ecc.

&CVS; è implementato come un sistema client-server. Come utente, tutta la comunicazione con il repository viene effettuata attraverso il programma a linea di comando &cvs;. Un livello più alto di interfaccia utente è disponibile attraverso frontend come Cervisia () o TkCVS ().In &kdevelop; può essere usata direttamente solo una piccola parte delle funzionalità di &cvs; che sono importanti per il lavoro quotidiano.

Viene supposta una conoscenza di base dell'uso di &CVS;. In particolare, si dovrebbe sapere come controllare un dato progetto nel repository. Viene raccomandato il libro Open Source Development With CVS di Karl Fogel che è distribuito liberamente (tranne i capitoli non-tecnici). Vedere .

### Comandi &CVS; in &kdevelop;

Nella visuale dei file, sono disponibili le seguenti voci del menu contestuale:

- #### Aggiungi al repository

  Predispone i file contrassegnati per l'aggiunta al repository. Il file viene trasferito al repository quando si effettua il commit del file (o della directory che lo contiene) la prossima volta.

- #### Remuovi dal repository

  Predispone un file per la rimozione dal repository. Questo cancella il file anche nel file system locale, quindi usare questa funzione con prudenza!

- #### Aggiorna

  Esegue `cvs update` per fondere tutti i cambiamenti degli altri utenti nella directory di lavoro. Quando si usa questa voce di menu su una directory normalmente l'aggiornamento viene fatto ricorsivamente, tranne il caso in cui questa opzione sia stata disabilitata nel file di configurazione `.cvsrc`.

- #### Commit

  Esegue il comando `cvs commit` per inviare tutte le modifiche locali al repository. Notare che si dovrebbe fare l'aggiornamento prima di dare questo comando, altrimenti nel caso che un altro utente abbia inviato nel frattempo le proprie modifiche &CVS; potrebbe dare un messaggio di errore.

Tutti questi comandi sono eseguiti da &kdevelop; come sottoprocessi senza nessuna opzione a linea di comando o variabile d'ambiente. Questo potrebbe costituire un problema se ci si connette con il server &CVS; attraverso una connessione &ssh; ed è richiesto l'inserimento di una password ogni volta che viene effettuato l'invio o l'aggiornamento. Ad esempio questo è necessario quando il proprio progetto è ospitato su `sourceforge.net`. Nella CVS/SSH FAQ che si può trovare nella documentazione di SourceForge sono descritte le soluzioni a questo problema.

### Dietro le quinte

#### Cosa registra &CVS; nella directory di lavoro

(... to be written ...)

## Programmi esterni

Sebbene &kdevelop; sia un cosiddetto ambiente di sviluppo integrato, non potrà mai contenere tutte le funzioni che si vorrebbero usare, e le capacità del suo editor non saranno mai sufficienti per eseguire tutti i compiti di elaborazione di testo che vengono spesso compiuti. Come ogni autentico programma UNIX, &kdevelop; contiene diverse possibilità di eseguire programmi esterni, plugin esterni necessari per lavorare con i file o filtri esterni per elaborare i contenuti dell'editor.

Una delle caratteristiche più generali e semplici è il menu degli strumenti, che si può configurare liberamente. Questo può essere fatto nella finestra di dialogo Impostazioni Configura KDevelop....in Strumenti esterni.

Other tools will be discussed in the chapter .

## Credits

### Contributions

- The initial contents of this manual were witten by Bernd Gehrmann bernd@kdevelop.org and Caleb Tennis caleb@aei-tech.com.

- The Summary of &automanag; and Automake Manager Operation chapters were written by Ian Wadham, ianw@netspace.net.au).

## Menus and Toolbars Survey

(... to be written ...)

## Shortcut Keys

(... to be written ...)

## Plugin

&kdevelop; contiene un grande numero di piccoli strumenti che aiutano ad eseguire alcuni compiti. La maggior parte di essi è realizzata come plugin. Questo significa che se uno di essi non piace può essere semplicemente disattivato nella finestra di dialogo Opzioni progetto... in Plugins (per i plugin generali) o inImpostazioni Configura KDevelop....I plugin che sono stati disattivati non disturbano i menu e non sono caricati in memoria.

- ### Il plugin `abbrev`

  Questo plugin espande le abbreviazioni in frammenti di codice molto usati. Si attiva premendo Ctrl Space. Per esempio, se si inseriscenell'editor `"ife"` in un file C++ e si premeCtrl Space, si ottiene un modello di codice `if-else` e si risparmia qualche battitura di tasti. L'insieme delle abbreviazioni supportate dipende dal linguaggio di programmazione del file che viene editato. Per esempio, per PHP si sarà ovviamente interessati ad altri modelli di codice rispetto a quelli di Java.

  L'insieme dei modelli di codice è configurabile. Si possono vedere quelli disponibili in Impostazioni Configura KDevelop...in Abbreviazioni

- ### Il plugin `filter`

  Questo plugin fornisce due funzioni. Se si seleziona Strumenti Esegui comando..., si può inserire un comando di shell. L'output del comando è inserito nel buffer dell'editor quando si preme il pulsante Avvia.

  La funzione relativa è disponibile in Strumenti Selezione filtro tramite comando.... Per usarla, si deve selezionare un'area di testo nell'editor. Se si inserisce un comando e si preme il pulsante Avvia esso verrà avviato e verrà usata la selezione come input. Lo standard output del comando viene quindi inserito nell'editor.

- ### Il plugin &doxygen;

  Questo plugin aiuta ad usare lo strumento di documentazione API &doxygen;(). Si può selezionare Project Run Doxygen per generare la documentazione API per il progetto corrente, in base alla configurazione del file `Doxyfile` della directory del progetto.

  Inoltre si può configurare &doxygen; nella finestra di dialogo Progetto Opzioni progetto.... Questa finestra di dialogo è molto simile alla procedura guidata &doxygen;.

- ### Il plugin &ctags;

  Sebbene il browser delle classi fornisca una vasta scelta di simboli e di classi del progetto, si potrebbe voler usare lo strumento ctags. In particolare esso supporta molti più linguaggi del browser delle classi.

  Si attiva questo plugin in Strumenti CTags.... Quando lo si avvia per la prima volta la prima richiesta sarà quella di generare un database di ricerca. Quando si accetta verrà avviato il programma &ctags; che creerà un file chiamato `tags` nella directory del progetto. Questo è un file di testo contenente tutti i simboli del file sorgente.

  Ci sono due modi per fare ricerche nel database: quando è selezionata la casellaCorrisp. espress. regolare il testo inserito sarà interpretato come espressione regolare (tipo POSIX) e confrontato con i simboli esistenti. Per esempio con il testo `.*Widget`verranno cercati tutti i simboli che finiscono con `Widget`. Se la casella non è selezionata la ricerca sarà fatta letteralmente.

  Quando viene fatta una ricerca si riceverà una lista di simboli corrispondenti accompagnati dal numero di linea del punto dove sono definiti. Cliccando sulla lista si salterà al punto relativo.

  Per alcuni linguaggi &ctags; distinguerà diversi tipi di simboli. Per esempio Python ha classi e funzioni. Si possono cercare selettivamente solo le classi selezionando il tipo relativo nella finestra di dialogo.

  Normalmente il database dei simboli non viene aggiornato quando si modificano i file sorgente. Di conseguenza dopo un po' i numeri di linea non saranno più corretti e mancheranno le nuove classi e funzioni. Perciò si dovrebbe aggiornare il file `tags` ad intervalli regolari premendo il pulsante Regenerate.

- ### Il plugin `astyle`

  (... to be written ...)

- ### Il plugin `regexptest`

  La progettazione con le espressioni regolari può diventare un lavoro pesante. Spesso al primo tentativo l'espressione corrisponde a troppe stringhe. In particolare, quando si lavora con un linguaggio compilato, i tempi di debug di una espressione regolare possono essere scomodi. Il plugin regexptest permette di esplorare direttamente i cambiamenti in una espressione regolare. Viene attivato con Strumenti Debug dell'espressione regolare.

  Nelle caselle si può scegliere il tipo di motore di espressioni regolari usato. Attualmente sono supportati il tipo definito dallo standard POSIX, usato dal programma &grep;, e la sintassi POSIX estesa usata dal programma &egrep;.

  Quando si inserisce un'espressione si riceverà un feedback immediato su ogni errore di sintassi. Inserendo un testo in Test stringa,si può vedere se l'espressione corrisponde alla stringa. In particolare, se l'espressione regolare include gruppi come `([a-z])`,viene visualizzato il contenuto del sottogruppo corrispondente in un elenco.

- ### Il plugin `konsole`

  (... to be written ...)

### Survey

&kdevelop; fornisce moduli estensibili o componenti, da caricare su richiesta al runtime. Questo permette agli sviluppatori di attivare solo le funzioni necessarie o desiderate per lo sviluppo.

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.

Altri componenti sono specifici del progetto, e sono utilizzati solo quando un progetto di quel tipo viene caricato. Ad esempio il gestore automake necessita di essere attivo quando viene caricato un progetto basato su automake. Altrimenti questo componente non è attivo.

I componenti attivi possono avere molti effetti su &kdevelop;. A seconda della loro funzione possono aggiungere menu extra, voci extra di menu, pulsanti degli strumenti extra, ecc.

#### Componenti di gestione del progetto in &kdevelop;

antproject | ANT Project Manager (applicazioni Java)
autoproject | Gestore di progetti automake
customproject | Gestore di progetti personalizzati
trollproject | Gestore di progetti basati su QMake

#### Componenti globali in &kdevelop;

Nome del componente | Descrizione
procedura guidata per le applicazioni | Procedura guidata Nuovo Progetto
history |
konsole | Konsole incorporata
editor-chooser | Sceglie un editor di testo interno
doctreeview | Visualizzatore di documentazione
openwith |
fileselector | Un widget di selezione dei file
uimode | Personalizza la modalità dell'interfaccia
texttools | Strumenti di testo aggiuntivi
tipofday | Suggerimenti del giorno
grepview | Una versione grafica dell'utility grep
cvs | Supporto per il CVS
strumenti |
regexptest | Un verificatore di espressioni regolari
abbrev | Espansore di abbreviazioni
filter |
valgrind | Un frontend grafico per valgrind

#### Componenti di supporto per il linguaggio in &kdevelop;

cppsupport | Supporto per C/C++
fortransupport | Supporto per Fortran
javasupport | Supporto per Java
perlsupport | Supporto per Perl
phpsupport | Supporto per PHP
pythonsupport | Supporto per Python

#### Componenti specifici del progetto in &kdevelop;

astyle |
buglist |
classview | Classview Manager
ctags |
debugger | Gestore del debugger &gnu;
diff |
distpart |
doxygen |
fileview |
javadebugger |
manager |
nedit |
outputviews |
perforce |
qeditor |
scripting |
scriptproject |
sourcenav |
svn |
visualboyadvance |
windowmenu |

## Esempi delle modalità dell'interfaccia utente di &kdevelop;

### IDEAl Mode

Click here to return to the modes survey.

Screenshot

Modalità IDEAl di &kdevelop;

Click here to return to the modes survey.

Screenshot

&kdevelop; IDEAl mode, closed tabs

This example screenshot demonstrates one of the main virtues of IDEAl mode. There is a maximum workspace available. Yet any tool view is readily available by clicking on the according tab.

You will most probably need some time to get accustomed to the icons in the tab bar. If you got lost, just position the mouse over a tab and wait a few seconds. A short tool tip description will pop up. In this screenshot the Automake Manager tool tip is shown as an example. It describes the lower tab in the right tab bar.

Click here to return to the modes survey.

### Child Frame Windows Mode

Click here to return to the modes survey.

Screenshot

Modalità finestre childframe di &kdevelop;

Click here to return to the modes survey.

### Tabbed Pages Mode

Click here to return to the modes survey.

Screenshot

Modalità a pagine etichettate di &kdevelop;

Click here to return to the modes survey.

### Toplevel Windows Mode

Click here to return to the modes survey.

Screenshot

Modalità finestre toplevel di &kdevelop;

Click here to return to the modes survey.

## Ulteriori informazioni

### Ricevere Informazioni

(... to be written ...)

### Segnalazioni di bug

(... to be written ...)

### Licenza

&underFDL; &underGPL;

## Cambiamenti

### Cambiamenti a questo documento

- 2003-01-03—Started this Changelog

## Bibliografia

(... to be written ...)