Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features.

BUG:215923


git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdevelop@1054174 283d02a7-25f6-0310-bc7c-ecb5cbfe19da

19 files changed, 2036 insertions, 0 deletions

diff --git a/doc/api/Architecture.dox b/doc/api/Architecture.dox
new file mode 100644
index 00000000..ae4ef73d
--- /dev/null
+++ b/doc/api/Architecture.dox
@@ -0,0 +1,315 @@
+/** \file  Architecture.dox
+  * \brief KDevelop architecture
+  */
+
+/** \page architecture KDevelop 3 Architecture
+
+KDevelop uses a plugin based architecture. This will be explained in more
+detail in the next sections. To add a new plugin check the \ref howToAddPlugins page.
+
+\section devteammodel Development Team cooperation model
+
+KDevelop is the result of the work of many people. To help syncronize the effords and to automate
+some tasks, the team uses many tools:
+
+  - CVS servers
+  - KDE Bugzilla
+  - Web servers
+  - Mailing Lists
+  - IRC
+  - Doxygen
+  - docbook
+  - LXR
+  - E-mail :)
+  - Cron Jobs
+  - and of course KDevelop :)
+  .
+
+They get interconnected like this:
+
+\image html Development.png
+
+
+\section overview Source Overview
+
+\subsection source-division Main Source Divisions
+
+The KDevelop 3 source is divided into several parts which correspond to
+subdirectories in the KDevelop project directory. There are several main
+parts to distinguish, mainly:
+
+  - src            = The core part of KDevelop
+  - lib/interfaces = Plugin handler interface classes
+  - parts          = The various parts using the KParts framework ( KDevPlugin children )
+  - languages      = \ref language-parts
+  - buildtools     = \ref buildtool-parts
+  - vcs            = \ref vcs-parts
+  - editors        = \ref editor-parts
+  .
+
+\image html Architecture.png
+
+This image is not complete there are parts that are not displayed. See below for a more detailed description.
+
+\subsection core-part The Core Part of KDevelop
+
+\subsubsection mainwindows Main Window Objects
+
+There are two types of possible main window objects:
+
+ - MainWindow implements standard MDI user interfaces:
+   - Top level mode (see MainWindow::switchToToplevelMode() )
+   - Childframe mode (see MainWindow::switchToChildframeMode() )
+   - Tab page mode (see MainWindow::switchToTabPageMode() )
+   - IDEAl mode (see MainWindow::switchToIDEAlMode() )
+   .
+ - MainWindowIDEAl implements an enhanced MDI main window providing a set of
+   pre-arranged access tabs around user areas.
+ .
+
+Both main window classes inherit from the KDevMainWindow class which provides
+access to common window features.
+
+\subsubsection toplevel The TopLevel Object
+
+There is only one toplevel object of class KDevMainWindow in KDevelop. It can
+be accessed through the static function TopLevel::getInstance() (see the
+TopLevel class).
+
+\subsection parts-overview KDevelop Parts Overview
+
+All parts reside in dedicated subdirectories acording to their function. They can
+be viewed according to their functionalities as follows.
+
+\subsubsection language-parts Programming Language Support Parts
+
+These parts implement a KDevLanguageSupport Class interface.
+To add support for a new programming language check the \ref howToAddProgrammingLanguages page (doc/api/HowToAddProgrammingLanguages.dox file).
+Take a look at \ref LangSupportStatus (doc/api/LangSupportStatus.dox file) to see the current status/features of the programming languages currently supported by KDevelop.
+
+  - languages/ada = Support for Ada
+    - (see AdaSupportPart)
+    .
+  - languages/bash = Support for bash
+    - (see BashSupportPart)
+    .
+  - languages/cpp = Support for C/C++
+    - (see CppSupportPart)
+      - languages/cpp/debugger = GNU Debugger frontend
+        - (see GDBDebugger::DebuggerPart)
+        .
+      .
+    .
+  - languages/fortran = Support for Fortran
+    - (see FortranSupportPart)
+    .
+  - languages/haskell = Support for Haskell
+    - (see HaskellSupportPart)
+    .
+  - languages/java = Support for Java
+    - (see JavaSupportPart)
+      - languages/java/degugger = Java debugger frontend
+        - (JAVADebugger::JavaDebuggerPart)
+        .
+      .
+    .
+  - languages/pascal = Support for Pascal
+    - (see PascalSupportPart)
+    .
+  - languages/perl = Support for Perl
+    - (see PerlSupportPart)
+    .
+  - languages/php = Support for PHP
+    - (see PHPSupportPart)
+    .
+  - languages/python = Support for Python
+    - (see PythonSupportPart)
+    .
+  - languages/ruby = Support for Ruby
+    - (see RubySupportPart)
+    .
+  - languages/sql = Support for SQL
+    - (see SQLSupportPart)
+    .
+  .
+
+\subsubsection buildtool-parts Build tools Parts
+
+These parts implement a KDevProject Class interface.
+
+  - buildtools/ada = Ada build tool
+    - (see AdaProjectPart)
+    .
+  - buildtools/ant = ANT build tool
+    - (see AntProjectPart)
+    .
+  - buildtools/autotools = Autotools build tool
+    - (see AutoProjectPart)
+    .
+  - buildtools/custommakefiles = Custom makefiles build tool
+    - (see CustomProjectPart)
+    .
+  - buildtools/generic = Generic build tool
+    - (see GenericProjectPart)
+    .
+  - buildtools/pascal = Pascal build tool
+    - (see PascalProjectPart)
+    .
+  - buildtools/script = Script build tool
+    - (see ScriptProjectPart)
+    .
+  - buildtools/qmake = QMake based build tool
+    - (see TrollProjectPart)
+    .
+  .
+
+
+\subsubsection vcs-parts VCS (Version Control System) Parts
+
+These parts implement a KDevVersionControl Class interface.
+
+  - vcs/cervisia = Cervisia Support
+    - (see CervisiaPlugin)
+    .
+  - vcs/clearcase = IBM Rational ClearCase Support
+    - (see ClearcasePart)
+    .
+  - vcs/cvs = CVS Support
+    - (see CvsPart)
+    .
+  - vcs/cvsservice = cvsservice Support (Cervisia interface)
+    - (see CvsServicePart)
+    .
+  - vcs/perforce = Version managment system perforce integration
+    - (see PerforcePart)
+    .
+  - vcs/subversion = Subversion integration
+    - (see subversionPart)
+    .
+  .
+
+
+\subsubsection editor-parts editor support Specific Parts
+
+These parts implement a KTextEditor Class interface.
+Take a look at \ref EditorsSupportStatus (doc/api/EditorsSupportStatus.dox file) to see the current status/features of the editors currently supported by KDevelop.
+
+  - editors/editor-chooser = Chooses an internal text editor
+    - (see EditorChooserPart)
+    .
+  - editors/nedit = KTextEditor interface for nedit
+    - (see KNEditFactory, Document, View)
+    .
+  - editors/qeditor = QEditor integration
+    - (see QEditorPart)
+    .
+  .
+
+
+\subsubsection global-parts Global Parts
+
+Some of the parts are considered global - that is, they effect the entire
+operation of KDevelop.
+
+These parts implement a KDevPlugin Class interface.
+
+  - parts/appwizard = New Project Wizard
+    - see AppWizardPart
+    - see \ref howToAddApplicationTemplates (doc/api/HowToAddApplicationTemplates.dox file)
+    .
+  - parts/history = Project history
+    - (see HistoryPart)
+    .
+  - parts/konsole = Embedded Konsole
+    - (see KonsoleViewPart)
+    .
+  - parts/doctreeview = Documentation Viewer
+    - (see DocTreeViewPart)
+    .
+  - parts/openwith = "Open with" menu addon
+    - (see OpenWithPart)
+    .
+  - parts/fileselector = A file selection widget
+    - (see FileSelectorPart)
+    .
+  - parts/uimode = Customize the UI mode
+    - (see UIChooserPart)
+    .
+  - parts/texttools = Additional text tools
+    - (see TextToolsPart)
+    .
+  - parts/tipofday = A tip of the day
+    - (see TipOfDayPart)
+    .
+  - parts/grepview = A graphical grep utility
+    - (see GrepViewPart)
+    .
+  - parts/tools = Toolbar management
+    - (see ToolsPart)
+    .
+  - parts/regexptest = A regular expression tester
+    - (see RegexpTestPart)
+    .
+  - parts/abbrev = Abbreviation Expansion
+    - (see AbbrevPart)
+    .
+  - parts/filter = Shell Filtering and Insertion
+    - (see FilterPart)
+    .
+  - parts/valgrind = A graphical valgrind frontend
+    - (see ValgrindPart)
+    .
+  .
+
+
+\subsubsection project-specific-parts Project Specific Parts
+
+These parts implement a KDevPlugin Class interface.
+
+  - parts/astyle = Source code formatter
+    - (see AStylePart)
+    .
+  - parts/buglist = Bug tracking application
+    - (see BugList)
+    .
+  - parts/classview = Classview Manager
+    - (see ClassViewPart)
+    .
+  - parts/ctags = CTags frontend
+    - (see CTagsPart)
+    .
+  - parts/diff = Difference viewer
+    - (see DiffPart)
+    .
+  - parts/distpart = Aids in building and publishing the final project
+    - (see DistpartPart)
+    .
+  - parts/doxygen = Doxygen integration
+    - (see DoxygenPart)
+    .
+  - parts/filecreate = New file creation
+    - see FileCreatePart
+    - see \ref howToAddFileTemplates (doc/api/HowToAddFileTemplates.dox file)
+    .
+  - parts/fileview = File groups
+    - (see FileViewPart, FileGroupsPart)
+    .
+  - parts/manager = Document manager
+    - (see DocManager, ViewManager)
+    .
+  - parts/outputviews = Application output views
+    - (see AppOutputViewPart, MakeViewPart)
+    .
+  - parts/scripting = Python scripting interface
+    - (see ScriptingPart)
+    .
+  - parts/sourcenav = Source code navigation
+    - (see SourceNavPart)
+    .
+  - parts/visualboyadvance = VisualBoy Advance integration
+    - (see VisualBoyAdvance::VisualBoyAdvancePart)
+    .
+  .
+
+*/
+
diff --git a/doc/api/Architecture.png b/doc/api/Architecture.png
new file mode 100644
index 00000000..306881fa
--- /dev/null
+++ b/doc/api/Architecture.png
diff --git a/doc/api/Architecture.sxd b/doc/api/Architecture.sxd
new file mode 100644
index 00000000..b48f9a36
--- /dev/null
+++ b/doc/api/Architecture.sxd
diff --git a/doc/api/Development.png b/doc/api/Development.png
new file mode 100644
index 00000000..063e63db
--- /dev/null
+++ b/doc/api/Development.png
diff --git a/doc/api/Development.sxd b/doc/api/Development.sxd
new file mode 100644
index 00000000..ff5b06cc
--- /dev/null
+++ b/doc/api/Development.sxd
diff --git a/doc/api/EditorsSupportStatus.dox b/doc/api/EditorsSupportStatus.dox
new file mode 100644
index 00000000..e826471c
--- /dev/null
+++ b/doc/api/EditorsSupportStatus.dox
@@ -0,0 +1,189 @@
+/** \file EditorsSupportStatus.dox
+  * \brief Editors Support Status
+  */
+
+/** \page EditorsSupportStatus Editors Support Status
+
+Kate and Kvim are part of KDE and KDevelop just uses them.
+
+qeditor and Nedit are interfaced via KDevelop's code. You can look at their code at <code>editors/qeditor</code> and <code>editors/nedit</code>.
+
+<table border="1" style="text-align: left; margin-left: auto; margin-right: auto;" cellpadding="2" cellspacing="2">
+    <tr>
+      <th style="text-align: center;">features/editor</th>
+      <th style="text-align: center;">kate</th>
+      <th style="text-align: center;">kvim (KDE 3.2)</th>
+      <th style="text-align: center;"><a href="classQEditor.html">qeditor</a></th>
+      <th style="text-align: center;"><a href="classKNEditFactory.html">Nedit (Disabled)</a></th>
+    </tr>
+    <tr>
+      <td style="background-color: rgb(51, 204, 0);">Advanced text editor</td>
+      <td style="background-color: rgb(51, 204, 0);"></td>
+      <td style="background-color: rgb(51, 204, 0);"></td>
+      <td style="background-color: rgb(51, 204, 0);"></td>
+      <td style="background-color: rgb(51, 204, 0);"></td>
+    </tr>
+    <tr>
+      <td>Open, close and save big text files</td>
+      <td>Y</td>
+      <td>N</td>
+      <td>Y</td>
+      <td>Y</td>
+    </tr>
+    <tr>
+      <td>Undo and redo</td>
+      <td>Y</td>
+      <td>N</td>
+      <td>Y</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>Jump in text: next/previous character, word.</td>
+      <td>Y</td>
+      <td>N</td>
+      <td>Y</td>
+      <td>Y</td>
+    </tr>
+    <tr>
+      <td>Jump to start or the end of the line/text</td>
+      <td>Y</td>
+      <td>N</td>
+      <td>Y</td>
+      <td>Y</td>
+    </tr>
+    <tr>
+      <td>Go to line</td>
+      <td>Y</td>
+      <td>N</td>
+      <td>Y</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>Select text when jumping (character, word, line), </td>
+      <td>Y</td>
+      <td>N</td>
+      <td>Y</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>Select all the text</td>
+      <td>Y</td>
+      <td>N</td>
+      <td>Y</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>Copy, paste and delete selections of text</td>
+      <td>Y</td>
+      <td>N</td>
+      <td>Y</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>Print</td>
+      <td>Y</td>
+      <td>N</td>
+      <td>Y</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td style="background-color: rgb(51, 204, 0);">Advanced text view:</td>
+      <td style="background-color: rgb(51, 204, 0);"></td>
+      <td style="background-color: rgb(51, 204, 0);"></td>
+      <td style="background-color: rgb(51, 204, 0);"></td>
+      <td style="background-color: rgb(51, 204, 0);"></td>
+    </tr>
+    <tr>
+      <td>Horizontal and vertical scrolling</td>
+      <td>Y</td>
+      <td>N</td>
+      <td>Y</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>Display selections</td>
+      <td>Y</td>
+      <td>N</td>
+      <td>Y</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>Mouse Wheel support</td>
+      <td>Y</td>
+      <td>N</td>
+      <td>Y</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>Dynamic word wrap</td>
+      <td>Y</td>
+      <td>N</td>
+      <td></td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>Line numbers</td>
+      <td>Y</td>
+      <td>N</td>
+      <td></td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>Show tabs</td>
+      <td>Y</td>
+      <td>N</td>
+      <td></td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>Find in file</td>
+      <td>Y</td>
+      <td>N</td>
+      <td>Y</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>Replace in file</td>
+      <td>Y</td>
+      <td>N</td>
+      <td>Y</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td style="background-color: rgb(51, 204, 0);">Coding specific properties:</td>
+      <td style="background-color: rgb(51, 204, 0);"><br></td>
+      <td style="background-color: rgb(51, 204, 0);"><br></td>
+      <td style="background-color: rgb(51, 204, 0);"><br></td>
+      <td style="background-color: rgb(51, 204, 0);"><br></td>
+    </tr>
+    <tr>
+      <td>Syntax highlighting</td>
+      <td>Y</td>
+      <td>N</td>
+      <td>Y</td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>Code folding</td>
+      <td>Y</td>
+      <td>N</td>
+      <td></td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>Spell</td>
+      <td>Y</td>
+      <td>N</td>
+      <td></td>
+      <td></td>
+    </tr>
+    <tr>
+      <td>Auto indendt</td>
+      <td>N</td>
+      <td>N</td>
+      <td>Y</td>
+      <td></td>
+    </tr>
+</table>
+
+*/
diff --git a/doc/api/FutureTasks.dox b/doc/api/FutureTasks.dox
new file mode 100644
index 00000000..fbed119a
--- /dev/null
+++ b/doc/api/FutureTasks.dox
@@ -0,0 +1,136 @@
+/** \file FutureTasks.dox
+  * \brief Future tasks and ideas for the next release of KDevelop
+  */
+/** \page FutureTasks Future tasks and ideas for the next release of KDevelop
+
+\section codereftodo Code Refactoring / Improvements:
+
+  - Core
+    - Make sure all lib interfaces are available via DCOP
+    - Find a nicer way to remove dynamic menu entries from context menus
+    - Resolve the path handling mess 
+    - Project name should be able to contain spaces
+    - Import existing directory: Should be named "Import existing project"
+      and more intuitive (wizard-like)
+      - Question from the wizard: "I have found C++ files in your
+        project directory. Should C++ be the primary language of your
+        project?" User: [Yes/No] =&gt; Next Step...
+      - Something intuitive for the binary/-ies (for debugger and
+        execution of program), libtool ([Yes/No] for the debugger), build
+        tool (qmake, automake,...?), etc.., too.
+    - use mimetype to determine code files, not extension
+      (see bug #
+    - Make the help buttons (that we already have) open the KDevelop Handbook on
+      the correct page (or the index if the subject is not covered yet).
+    - New and improved VCS framework (Needs better description)
+    - Another look at the plugin system (Nees better description)
+    - Another look at the project files (shared, non-shared, session)
+    - fix(redesign?) project language switching
+    - editor handling could be made a bit saner if editor plugin switching was an after-restart-only feature
+    
+  - Programming Language Support Parts
+    - Create base classes for language support parts:
+      - AntlrLanguageSupport
+      - AntlrBackgroundParser
+      - AntlrProblemReporter
+    - Same for:
+      - YaccLanguageSupport
+      - YaccBackgroundParser
+      - YaccProblemReporter
+    - There is a possibility to create even something like
+      - LanguageSupportBase
+
+    Look at java, pascal and ada support parts to get more inspiration. 
+    There should be base classes for ada, java and pascal language supports - too much code duplication.
+ 
+    - CppSupportPart
+      - Extended "make member" functionality - run on a .h to implement stubs for all unimplemented non-abstract methods
+      - Code Refactoring
+    - text hint type info tooltips (edit mode)
+    - text hint value info tooltips (debug mode)
+    - Make the language plugin know stuff like what file patterns to look for (for instance, "find in files" needs this)
+    
+  - Build tools Parts
+    - Show .po files in project management
+    - Custom actions for groups, targets and files for project managers:
+      - any menu item should be a KAction plugged into KPopupMenu, also we need to define shortcuts for any such action,
+        also we should make sure those actions are properly executed from a shortcut.
+    - AutoProjectPart
+      - Should be able to DND files from other targets / file list / konq to add to targets
+      - Should loose the experimental crashy and nonstandard "add files" dialog
+      - Update configure.in when sub projects are added and the project doesn't use am_edit
+    - Keep the correctly cased project name and save it to the project file
+
+  - Debugger Parts
+    - Create a debugger support base classes. Make the current GDB support a plugin.
+    - Implement parts for other debuggers i.e. DBX, WDB, Ladebug, JDB, XDB, bashdb, the Perl debugger, or the Python debugger.
+      We can use DDD as inspiration.
+    - General debugger
+      - variable widget
+        - set variable by editing the value in the tree
+        - cast value by editing the type in the tree
+      - disassembly
+        - add breakpoint display
+        - set breakpoint by selecting a line as in the edit window
+        - allow scrolling of disassembled code about and below current limits
+        - add source to disassembled code as comments
+        - basically just re-work the whole disassemble window :)
+      - Bugs
+        - Fix "core file" handling
+        - Fix "attach to" handling
+        - Breakpoints can disappear at odd times
+        - When the target program crashes, the debugger can't be started again. (intermittant?)
+        - Break on method() - could have multiple methods which require a choice. How to handle this?
+
+
+  - Plugins
+    - DocTreeViewPart
+      - Implement plugin system for doctreeview.
+      - improve documentation browsing
+      - Check if a man page exists before offering the context menu item 'Goto manpage'
+      - right click -> set as bookmark in docviewer
+    - ClassViewPart
+      - Implement language-dependant plugin system for classview:
+      - namespaces/classes/functions are not always applicable to a language, we need a way to correctly
+        fill a class view and combo boxes - only a language support can do that properly.
+      - Distinguish vanilla c++ support from c++ + Qt extensions and show signals/slots in the class view only with Qt. (is this still valid?)
+    - KonsoleViewPart
+      - Perhaps use konsole part for the application frontend
+      - cd's when selecting a file, but doesn't when selecting a dir,
+        desired: a menu option to "cd" to that directory
+    - QEditor
+      - Replace editors/qeditor/koReplace.* and editors/qeditor/koFind.* with kdelibs/kutils/kreplace.* and kdelibs/kutils/kfind.*
+
+    
+\section extensiontodo Extensions / New Functionality:
+
+  - Core
+    - implement multiple-views per document (why?)
+    - Document manager (not obviously useful)
+    - Implement Add Plugin 
+    - Show intro page on startup
+  - Programming Language Support Parts
+  - Build tools Parts
+  - Plugins
+    - better sourcenav part (all navigation tools should be supported with at least a "back" action - forward much less important)
+    - Integrate kontact's TODO-List and knotes plugin. (We need something like a
+      server/client system that all the knotes/toto-clients are always synced.)
+    - a generic macro-tool (if possible, probably best implemented as a KTE plugin)
+    - Free grouping of files in file group plugin
+
+
+\section misctodo Miscellaneous (and possibly invalid) items:
+   
+  - UI bugs
+    - Editor options dialog missing when all views are closed (virtually impossible to fix)
+    - If you click an error in the output view, "Next Error"/"Previous
+      Error" should then start from that point (already implemented?)
+    - Messages in status bar would look nicer if they appeared with
+      the same border as other items (impossible)
+    - Browser tool bar should truncate long menu entries so it doesn't
+      take so much space (already implemented?)
+    - Extend KDevPlugin-API in order to have a preferred border for at
+      least the selection parts (Automake Manager, Class Browser, File
+      Groups, etc...)
+
+*/
diff --git a/doc/api/HighPriTasks.dox b/doc/api/HighPriTasks.dox
new file mode 100644
index 00000000..21116342
--- /dev/null
+++ b/doc/api/HighPriTasks.dox
@@ -0,0 +1,36 @@
+/** \file HighPriTasks.dox
+  * \brief High priority tasks
+  */
+/** \page HighPriTasks High priority tasks!
+
+\section fixMajBugs Fixing major/annoying bugs
+
+  - Fix the mess of .kdevelop and .kdevses file.
+    - All project wide setings should go into .kdevelop and
+    - all session (and personal) options should go into .kdevses file
+    .
+    This way the .kdevelop file can be shared in teams of developers.
+
+
+\section KDevelop2compat KDevelop 2 compatibility
+(These are things that must be accomplished before we can say that KDevelop 3
+&gt;= kdevelop 2.x UI-wise and functionality-wise!)
+
+  - general UI issues:
+    - toplevel UI mode broken concerning to the accels
+    - [Modified] missing in mainframe caption
+    - captions missing for toolbar buttons
+    .
+  - build/configuration:
+    - cross-compiling feature missing
+    - make "MIN_VERSION" configurable on new project creation
+    .
+  - doctreeview:
+    - implement "Make User Manual"
+    - use kdoc to update Qt/KDE docs
+    .
+  - Solve the regression bugs. These are the <a href= "http://bugs.kde.org/buglist.cgi?product=kdevelop&bug_status=UNCONFIRMED&bug_status=NEW&priority=HI">ones
+marked with priority "HI" in the bug database</a>
+
+
+*/
diff --git a/doc/api/HowToAddApplicationTemplates.dox b/doc/api/HowToAddApplicationTemplates.dox
new file mode 100644
index 00000000..7eec80c7
--- /dev/null
+++ b/doc/api/HowToAddApplicationTemplates.dox
@@ -0,0 +1,285 @@
+/** \file HowToAddApplicationTemplates.dox
+  * \brief How to add application templates to the application wizard part
+  */
+/** \page howToAddApplicationTemplates How to add application templates to the application wizard part
+
+Project templates provide the developer with a basic application framework.
+This is necessary for rapid application development (RAD) and makes it even possible
+for an inexperienced 3rd party developer to create standard conforming
+applications like kedit as well as plugins for example for kdevelop or noatun.\n\n
+\ref templates_1\n
+    - \ref templates_1_1
+    - \ref templates_1_2
+        - \ref templates_1_2a
+        - \ref templates_1_2b
+        - \ref templates_1_2c
+        - \ref templates_1_2d
+        - \ref templates_1_2e
+        .
+    .
+\ref templates_2\n
+\ref templates_3\n
+\ref templates_4\n
+<!-- @todo <b>Developer information:</b> The documentation for the related
+<code>"Project"->"Import Existing Project..."</code> is available here: \ref appwizard_imports
+-->
+<hr>
+
+\section templates_1 I. Example: How To Create a Simple KDE Application Template "KHello"
+
+You can find this template in <code>$KDEDIR/share/apps/kdevappwizard/template-khello</code>.
+
+\subsection templates_1_1 I.1. Step 1: Basic Skeleton
+
+Create a directory <code>template-khello</code> with the files
+<code><pre>
+    - template-khello/app.cpp
+    - template-khello/app.h
+    - template-khello/app.desktop
+    - template-khello/app.kdevelop
+    - template-khello/appui.rc
+    - template-khello/khello
+    - template-khello/main.cpp
+    - template-khello/preview.png
+    - template-khello/script
+    - template-khello/src-Makefile.am
+    - template-khello/subdirs
+    .
+</pre></code>
+\note The directory name must begin with <code>"template-"</code>.
+
+\subsection templates_1_2 I.2. Step 2: The Files in Detail
+
+Have a look into the files! There are some variables which the application
+wizard will replace:
+<code><pre>
+    - \%{AUTHOR} ...... by the author
+    - \%{EMAIL} ....... by the e-mail address 
+    - \%{VERSION} ..... by the version
+    - \%{APPNAME} ..... by the project name (KHello)
+    - \%{APPNAMELC} ... by the project name in lowercase (khello)
+    - \%{APPNAMEUC} ... by the project name in uppercase (KHELLO)
+    - \%{LICENSE} ..... by the license (GPL, BSD, QPL, LGPL, ...)
+    - \%{LICENSEFILE} . by the licensefile
+    - \%{YEAR} ........ by the year
+    .
+</pre></code>
+All this can be found in <code>$KDEDIR/share/apps/kdevappwizard/template-common/kdevelop.pm</code>.
+\subsubsection templates_1_2a I.2.1. The Source Files
+
+The files <code>template-khello/app.cpp, template-khello/app.h</code> and
+<code>template-khello/main.cpp</code> contain the source code that should not
+be too special so that the user can implement his own ideas.\n
+(There may be variables included - see \ref templates_1_2 "Step 2: The Files in Detail").
+
+\subsubsection templates_1_2b I.2.2. The File template-khello/khello
+
+It may look like this:
+\verbinclude khello/khello
+
+The application wizard looks into this file to get
+    - the information where to integrate the plugin into the the listview (<code>Category=</code>)
+    - the name (<code>Name=</code>) and the comment (<code>Comment=</code>)
+    - the preview image (<code>Icon=</code>)
+    - and the file templates the project uses (<code>FileTemplates=</code>).
+    .
+Further information could be (not required):
+    - <code>Comment=</code> a small comment for the template. Longer comments should go into a README.devel and shown on startup
+    - <code>ShowFilesAfterGeneration=</code> a comma-separated list (without whitespaces) of files that should be opened immediately after the generation, for instance a README.devel or a source file the user has to modify, the path is relative to the project directory (example: <code>ShowFilesAfterGeneration=src/main.cpp,src/plugin.cpp</code>). And
+        - <code>APPNAMEUC</code> will be replaced with the projectname in uppercase,
+        - <code>APPNAMELC</code> will be replaced with the projectname in lowercase,
+        - <code>APPNAME</code> will be replaced with the projectname.
+        .
+    - <code>DefaultDestinatonDir</code> changes the default destination dir for the project (~) to your value, whereas <code>HOMEDIR</code> is a keyword
+    .
+
+\attention The file <code>template-khello/khello</code> must have the same name as
+the right half of the directory! If the directory is <code>template-foobar</code>
+the file must be <code>template-foobar/foobar</code>.
+
+\see AppWizardPart for more information.
+
+\subsubsection templates_1_2c I.2.3. Some Additional Files
+
+The file
+    - <code>template-khello/appui.rc</code> contains information about the toolbar and the menu.
+    - <code>template-khello/preview.png</code> will be shown in the aplication wizard.
+    - <code>template-khello/app.desktop</code> describes the application.
+    - <code>template-khello/subdirs</code> contains a list of the subdirectories (usually <code>doc, po, src</code>) and can be found in the project root directory. It is necessary for the autotools.
+    .
+
+\subsubsection templates_1_2d I.2.4. The File template-khello/src-Makefile.am
+
+This file will be copied to the <code>$PROJECTDIR/src/</code>.
+\verbinclude khello/src-Makefile.am
+
+\subsubsection templates_1_2e I.2.5. The File template-khello/script
+
+The following script is used to install the template and replaces all
+variables by the corresponding value. The result is a hopefully working
+kdevelop project!
+\verbinclude khello/script
+<br>
+\note There are several application templates which use some identical
+files - that's why some files are taken from the <code>"template-common"</code>-directory.
+
+\section templates_2 II. Registration/Installation Of The Application Template
+
+The easiest way to install your template is to provide an "install.sh" shell script.\n
+Example:
+\code
+#!/bin/sh
+
+kde_prefix=`kde-config --prefix`
+if  [ `id -u` = 0 ]; then
+  # we are root so install the template into the global kde directory
+  kde_dir=`kde-config --prefix`
+else
+  # we are a user so install it into $HOME/.kde/share/apps/kdevappwizard directory
+  kde_dir=`kde-config --localprefix`
+  echo "Note: It would be better to install as root. Press CTRL+C to abort"
+fi
+
+# use usual path or another one?
+echo "Install dir [${kde_dir}/share/apps/kdevappwizard]:"
+read newdir
+
+if [ "$newdir"a = a ]; then newdir="${kde_dir}/share/apps/kdevappwizard/"; fi
+
+# make sure the directories exist
+if [ ! -e "${newdir}/template-khello" ]; then mkdir -p "${newdir}/template-khello" ; fi;
+if [ ! -e "${newdir}/templates" ]; then mkdir -p "${newdir}/templates" ; fi;
+if [ ! -e "${newdir}" ]; then mkdir -p "$newdir" ; fi;
+if [ ! -e "${newdir}/template-common" ]; then ln -s "${kde_prefix}/share/apps/kdevappwizard/template-common" "${newdir}/template-common" ; fi;
+
+# install now
+cp -R --target-directory "$newdir" template-khello
+# the file template-khello/khello must go to the "templates" directory that
+# kdevelop knows that it exists
+mv "$newdir/template-khello/khello" "$newdir/templates/"
+echo "done"
+\endcode
+\n
+\attention Please test your template whether it installs and behaves correctly! Test, test and test again! ;)
+
+\section templates_3 III. How To Add The Template To KDevelop CVS HEAD
+
+This section is for kdevelop developers only. Most probably you don't have to read this!.\n
+Move the directory <code>"template-khello"</code> to <code>kdevelop/languages/cpp/app_templates/</code>
+and then add the following files in <code>kdevelop/languages/cpp/app_templates/template-khello/</code>
+(in this example the language is c++ if you use other language replace cpp with the language name):
+    - <code>".kdev_ignore"</code> is an empty file. It prevents KDevelop's
+    C++-parser from parsing the C++ template files. This is necessary because the template files are just code templates and not real code (yet).
+    - <code>".cvsignore"</code> looks like this:
+\code
+Makefile
+Makefile.in
+script.local
+\endcode
+    - <code>"Makefile.am"</code> looks like this:
+    \verbinclude khello/Makefile.am
+    .
+Finally add <code>"template-khello"</code> to "SUBDIRS = " in <code>kdevelop/languages/cpp/app_templates/Makefile.am</code>.\n
+\attention Please test your template whether it installs and behaves correctly!
+Test, test and test again! It works? Well - now talk to the kdevelop guys so
+that they know what's going on and probably you may commit. ;)
+
+\section templates_4 IV. Changes to the template system (VERY IMPORTANT)
+
+The entire app template system described above has been changed.
+To port a template to the new system the
+information from the script file will need to be moved into the ini file.
+The example is as follows:
+\code
+install(
+"${src}/template-chello/app.kdevelop","${dest}/${APPNAMELC}.kdevelop" );
+\endcode
+becomes
+\code
+[PROJECT]
+Type=install
+Source=%{src}/template-chello/app.kdevelop
+Dest=%{dest}/%{APPNAMELC}.kdevelop
+\endcode
+
+Things like <code>installIncAdmin();</code> and <code>installGNU();</code> now involve unpacking
+the tar archives.  This is done by creating a target in the ini file as
+follows:
+\code
+[GNU]
+Type=install archive
+Source=%{src}/template-common/gnu.tar.gz
+Dest=%{dest}
+\endcode
+
+The popular script functions convert as follows:
+\code
+installIncAdmin(); %{src}/template-common/incadmin.tar.gz
+installGNU();  %{src}/template-common/gnu.tar.gz
+installAdmin(); %{src}/template-common/admin.tar.gz
+installGnome(); %{src}/template-common/gnome.tar.gz
+installWX(); %{src}/template-common/wxwidgets.tar.gz
+\endcode
+
+
+To create directories is now:
+\code
+[SRC]
+Type= mkdir
+Dir=%{dest}/src
+\endcode
+
+New additions are as follows:
+\code
+[MGS]
+Type=message
+Comment=A simple C project was created in %{dest}.
+\endcode
+
+Will allow you to display a custom message when the template has
+finished installing.  This is very handy for projects that require
+custom variables to be set.
+
+The concept of custom variables was also introduced.  To create a
+variable that can be edited from the project wizard you need to add an
+entry as follows:
+\code
+[LIBS]
+Type = value
+ValueType=<Qt Data type>
+Value= <Value Name that will be substituted in the code>
+Comment= <The label in the UI>
+Default= <The default value>
+\endcode
+
+One special value can be used to turn targets on and off.  This is done
+by adding a value as follows:
+\code
+[DOCSOPT]
+Type = value
+ValueType=bool
+Value=INSTALL_DOCS
+Comment= Install Docbook documentation templates.
+Default=true
+\endcode
+
+Then in the targets you wish to make optional you add the Option
+property with the value's name as the data. This will look as follows:
+\code
+[DOCSDIREN]
+Type=mkdir
+Dir=%{dest}/doc/en
+Option=INSTALL_DOCS
+\endcode
+
+The Option target is available to the mkdir, install, and install
+archive targets.
+
+The last new addition is the optional post processing of the files as
+they are copied.  For install and install archive you can add a
+<code>Process=true</code> or <code>Process=false</code> to turn the processing on or off.
+
+A note on the UI. its not final, it will get better.  Suggestions or
+bugs should be noted asap.
+
+*/
diff --git a/doc/api/HowToAddFileTemplates.dox b/doc/api/HowToAddFileTemplates.dox
new file mode 100644
index 00000000..fa6e630b
--- /dev/null
+++ b/doc/api/HowToAddFileTemplates.dox
@@ -0,0 +1,30 @@
+/** \file HowToAddFileTemplates.dox
+  * \brief How to add file templates to the file create part
+  */
+/** \page howToAddFileTemplates How to add file templates to the file create part
+
+File templates provide the developer with a basic file.  They are prototypes for both source files of
+the project's language, and for other files that may be useful in the project. For example, a C++
+project may have templates for both .cpp and .h files, plus QT Designer .ui files, and supporting
+files such as XML.
+
+These prototypes are placed in <code>parts/filecreate/file-templates</code> dir or
+<code>languages/YOURLANGUAGE/file_templates</code> and have names equal to the extensions of language
+source files.
+
+Sometimes, different 'flavours' of template are required for a particular file type. In these
+instances, 'subtypes' can be defined to allow several different templates for a file type. An example
+of this are QT designer '.ui' files. KDevelop supplies several different templates for .ui
+files. Subtypes are named by the file type extension followed by a hyphen followed by an identifier
+for the subtype. E.g. ui-widget, ui-dialog
+
+The description of the prototypes is placed in <code>parts/filecreate/template-info.xml</code>. This
+file is fairly self-explanatory if you take a look at it.
+
+Note that templates and templates information can be edited within KDevelop itself. The global
+templates that can be made available to any project can be changed in Settings / Configure KDevelop... / New File
+Wizard; and project related settings can be changed in Project / Project Options / New File Wizard.
+
+That's all! :)
+
+*/
diff --git a/doc/api/HowToAddGenericBuildTools.dox b/doc/api/HowToAddGenericBuildTools.dox
new file mode 100644
index 00000000..b073cf0f
--- /dev/null
+++ b/doc/api/HowToAddGenericBuildTools.dox
@@ -0,0 +1,21 @@
+/** \file HowToAddGenericBuildTools.dox
+  * \brief How to add a generic build tool plugins to the generic build tool part
+  */
+
+/** \page howToAddGenericBuildTools How to add a generic build tool plugins to the generic build tool part
+
+This part offers build tool facilities using project files in xml format (dtd is located in buildtools/generic/kdevxmlproject.dtd).
+Those xml files can be converted into makefiles, ant xml files or simply shell scripts using build system plugins.
+Build system plugin is an object that implements KDevBuildSystem interface.
+Build system plugins are located in buildtools/generic/buildsystem.
+
+\section sectionStep1 Step 1: Make your plugin loadable
+
+For a plugin <code>foo</code>, create a file <code>foo.desktop</code> which contains KDevelop/Part in its list of ServiceTypes.
+
+The rest of this document is to be written.
+
+Document your plugin in the way described at \ref howToDocument (doc/api/HowToDocument.dox file).
+
+*/
+
diff --git a/doc/api/HowToAddPlugins.dox b/doc/api/HowToAddPlugins.dox
new file mode 100644
index 00000000..ce8f259a
--- /dev/null
+++ b/doc/api/HowToAddPlugins.dox
@@ -0,0 +1,204 @@
+/** \file HowToAddPlugins.dox
+  * \brief How to extend KDevelop via plugins
+  */
+
+/** \page howToAddPlugins How to extend KDevelop via plugins
+
+\section createDesktop Step 1: Make your plugin loadable
+
+For a plugin <code>foo</code>, create a file <code>foo.desktop</code> which contains KDevelop/Part in its list of ServiceTypes.
+
+  - See <code>parts/doctreeview/kdevdoctreeview.desktop</code> for an example.
+  .
+
+If you install this file into <code>\$(kde_servicesdir)</code>, your plugin will automatically be loaded.
+
+\subsection changeLoading How to change the default loading
+
+You can change the default loading by changing some settings in your <code>foo.desktop</code> file:
+
+  - Set <code>X-KDevelop-Scope=</code> to <code>Global</code> or
+    <code>Project</code>
+    - <b>Note:</b> This property is <i>not</i> optional
+	.
+  - You can add a list of programming languages which are supported by your
+    plugin
+	- If your plugin works with all languages leave the
+	  <code>X-KDevelop-ProgrammingLanguages=</code> field empty
+	  <i>(optional)</i>
+	.
+  - You can add a list of keywords.
+    - The plugin will only be loaded if all keywords match with the
+	<code>Keywords=</code> field in the projectfile <i>(optional)</i>.
+	.
+  .
+
+An example from the Java Debugger Plugin:
+
+<code><pre>
+    #######################
+    X-KDevelop-Scope=Project
+    X-KDevelop-ProgrammingLanguages=Java
+    Keywords=
+    ##########################
+</pre></code>
+    
+
+\section createFactory Step 2: Make the plugin accessible by the factory
+
+Create a factory class <code>FooFactory</code> which inherits
+<code>KDevFactory</code>. Put a section
+
+<code><pre>
+    extern "C" {
+        void *init_libfoo()
+        {
+            return new FooFactory;
+        }
+    }
+</pre></code>
+
+into the source file, so that the factory can be accessed by KDE's library
+loader. Keep in mind that the name of the method <code>init_libfoo()</code> is
+required for a library with the name <code>libfoo.so</code>.
+
+This may be simplified by the use of the
+<code>K_EXPORT_COMPONENT_FACTORY</code> macro which is defined in
+<code>klibloader.h</code>:
+
+<code>
+K_EXPORT_COMPONENT_FACTORY( libfoo, FooFactory );
+</code>
+
+  - <i>Note:</i> Your factory must reimplement the
+    <code>createPartObject()</code> method of <code>KDevFactory</code> and
+	produce the part there.
+  .
+
+See <code>parts/doctreeview/doctreeviewfactory.cpp</code> for an example.
+
+
+\section implementPart Step 3: Implement your part.
+
+Your part must be derived from <code>KDevPlugin</code>.
+
+  - KDevPlugin takes two arguments:
+    - 1) A <i>parent</i> argument. This also comes from
+	  <code>createPartObject()</code>.
+	- 2) A <i>name</i>, which in turn is given to the <code>QObject</code>
+	  constructor.
+	.
+  .
+
+\subsection accessIDE How to access other IDE components
+
+A part can access other components of the IDE via some accessors
+of <code>KDevPlugin</code>:
+
+  - The <i>application core</i> via <code>core()</code>,
+  - the <i>build tools</i> via <code>project()</code>,
+  - the <i>programming language specific stuff</i> via
+    <code>languageSupport()</code>,
+  - the <i>make frontend</i> via <code>makeFrontend()</code>,
+  - the part which displays <i>appication output</i> via
+    <code>appFrontend()</code>,
+    and finally
+  - the <i>symbol database</i> via <code>classStore()</code>.
+  .
+
+In order to see what these components provide, see <code>lib/interfaces/kdev*.h</code>.
+
+\subsection userPrefs How to store user preferences
+
+Parts can also store user preferences on a per-project basis. To this
+end, they can access a <code>QDomDocument</code> representing the project file
+(which is stored as xml) via <code>document()</code>.
+
+Take attention to the issue that the project file usually is shared in a team of
+developers (e.g. via version control application CVS). So some user preferences might be
+very individual, and some may be valid for all of the team - project-wide so to speak.
+
+That's why the KDevelop architecture makes a difference here and supports two files
+which will be stored in the project root directory. They are the project file (*.kdevelop)
+and the session (*.kdevses) file. The later is for individual settings, not to be thought
+to be shared.
+
+\subsection domProject Project file (*.kdevelop)
+
+For your convenience, you don't have to use the quite complex DOM API. Strings
+can very easily be read from and written to this document using the
+<code>DomUtil</code> class. Here, entries are identified by a 'path' in the
+document. You can think of the DOM document as representing a file system
+rooted in the <code>dom</code> document node.
+
+For example, the <code>autoproject</code> part uses the statement
+
+<code><pre>
+    QString cflags = DomUtil::readEntry( *part->document(),
+                                         "/kdevautoproject/cflags" );
+</pre></code>
+
+to read the <code>CFLAGS</code> variable set by the user, and uses the statement similar to
+
+<code><pre>
+    DomUtil::writeEntry( *part->document(),
+                         "kdevautoproject/cflags",
+                         "--no-exceptions" );
+</pre></code>
+
+to write it back.
+
+  - <i>Note:</i> In order to avoid conflicts between different plugins, you
+    should use your part name as top-level 'directory' in the configuration
+	tree.
+  .
+
+\subsection sessionAccess Project session file (*.kdevses)
+
+The base class of all KDevelop plugins is KDevPlugin. It provides two virtual methods 
+restorePartialProjectSession(..) and savePartialProjectSession(..)
+that you should reimplement in your special plugin to attach to session loading and saving.
+
+When KDevelop loads or closes a project, the program's project session manager
+(class ProjectSession) calls them for each plugin. That manager gives a QDOM node to the
+plugin where it can read out or build up its partial DOM subtree with the session settings.
+That subtree will be stored in the .kdevses file by that session manager.
+
+For example each programmer has set breakpoints in different files than the other ones of
+the team. So the debugger plugin saves them to project session file:
+
+<code><pre>
+void DebuggerPart::savePartialProjectSession(QDomElement* el)
+{
+    gdbBreakpointWidget->savePartialProjectSession(el);
+}
+void GDBBreakpointWidget::savePartialProjectSession(QDomElement* el)
+{
+    QDomDocument domDoc = el->ownerDocument();
+    if (domDoc.isNull()) return;
+    QDomElement breakpointListEl = domDoc.createElement("breakpointList");
+    for ( int row = 0; row < m_table->numRows(); row++ )
+    {
+        BreakpointTableRow* btr = (BreakpointTableRow *) m_table->item(row, Control);
+        Breakpoint* bp = btr->breakpoint();
+        QDomElement breakpointEl = domDoc.createElement("breakpoint"+QString::number(row));
+        breakpointEl.setAttribute("type", bp->type());
+        breakpointEl.setAttribute("location", bp->location(false));
+        breakpointEl.setAttribute("enabled", bp->isEnabled());
+        breakpointEl.setAttribute("condition", bp->conditional());
+        breakpointListEl.appendChild(breakpointEl);
+    }
+    if (!breakpointListEl.isNull()) el->appendChild(breakpointListEl);
+}
+
+}
+</pre></code>
+
+Note that the .kdevses is related to a project. User settings equal for all projects don't
+belong to here. You save them to ~/.kde/share/config/kdeveloprc via class KConfig of the
+kdecore library.
+
+Document your part in the way described at \ref howToDocument (doc/api/HowToDocument.dox file).
+
+*/
+
diff --git a/doc/api/HowToAddProgrammingLanguages.dox b/doc/api/HowToAddProgrammingLanguages.dox
new file mode 100644
index 00000000..5cfa3643
--- /dev/null
+++ b/doc/api/HowToAddProgrammingLanguages.dox
@@ -0,0 +1,252 @@
+/** \file HowToAddProgrammingLanguages.dox
+  * \brief How to add support for a programming language
+  */
+
+/** \page howToAddProgrammingLanguages How to add support for a programming language
+
+\section LSupport List of things to have "complete" support of a given language in KDevelop
+
+  - Implement interface KDevLanguageSupport
+  - \ref sectionClassWizard
+  - \ref sectionAttributeMethodWizard
+  - \ref sectionQtUiSubclassing - (if the language has Qt bindings)
+  - \ref sectionLanguageParser
+  - \ref sectionClassStore
+    - \ref sectionMemoryClassStore
+    - \ref sectionPersistantClassStore
+    .
+  - \ref sectionCodeCompletion
+  - \ref sectionProblemReporter - (parses source on the fly and reports syntax errors)
+  - \ref sectionTemplates
+    - \ref sectionApplicationTemplates
+    - \ref sectionApplicationImportTemplates
+    - \ref sectionSourceFileTemplates
+    - \ref sectionAbbreviationTemplates - (ife expands to an if else statement, etc)
+    .
+  - \ref sectionSourceCodeFormater (prettyprint functionality)
+  - \ref sectionDocumentationTopics
+  - \ref sectionDebugger
+    - (gdb/jdb/??? integration)
+  - \ref sectionCompilerPlugins
+  .
+
+List of optional things to support a given language in KDevelop:
+  - \ref sectionEditor - Syntax highlighter - (add to QEditor if not available elsewhere)
+  - \ref sectionBuildTool (make/ant/etc)
+  .
+
+Take a look at \ref LangSupportStatus (doc/api/LangSupportStatus.dox file) to see the current status/features of the programming languages currently supported by KDevelop.
+
+
+
+
+\section sectionLanguageSupport Language Support
+
+Any language support should be written as a kdevelop part and implement
+KDevLanguageSupport interface (<code>lib/interfaces/kdevlanguagesupport.h</code>).
+
+Implementing methods:
+ - <code>virtual Features features();</code>
+ - <code>virtual KMimeType::List mimeTypes();</code>
+ .
+
+Should be enough for a language support to start working.
+
+KDevelop ships with KDevLang project template. It is a simple language support prototype that can be used when developing language support plugins with KDevelop.
+To use it, start a New Project and select: <code>C++->KDevelop->KDevelop Language Support Plugin</code> in the application wizard.
+The template is located in <code>languages/cpp/app_templates/kdevlang</code>, you can change it there if you need.
+
+
+You should look at <code>languages/ruby</code> for a simple language support
+implementation. For a compilable language support, consult <code>languages/ada</code> or <code>languages/pascal</code> (they are not so complex as <code>languages/cpp</code>).
+
+Pascal would be a good starting place, as it is the smaller of the two by far.
+
+Language support can offer additional features:
+
+\subsection sectionClassWizard Class wizard
+  - new class wizard: (See <code>ada, php, cpp</code> or <code>java</code>)
+    - <code>virtual void addClass();</code>
+    .
+
+\subsection sectionAttributeMethodWizard Attribute/Method wizard
+  - add method dialog: (See <code>cpp</code> or <code>java</code>)
+    - <code>virtual void addMethod(const QString &className);</code>
+    .
+  - add attribute dialog: (See <code>cpp</code> or <code>java</code>)
+    - <code>virtual void addAttribute(const QString &className);</code>
+    .
+  .
+
+\subsection sectionQtUiSubclassing Qt UI subclassing
+
+If there is a Qt bindings for your language and there is a possibility
+to use QtDesigner ui files, you could implement ui subclassing feature:
+  - <code>virtual QStringList subclassWidget(const QString& formName);</code>
+  - <code>virtual QStringList updateWidget(const QString& formName, const QString&
+        fileName);</code>
+  .
+
+See <code>cpp</code> and <code>java</code> for examples.
+
+\subsection sectionLanguageParser Language parser
+
+In general, class stores can be filled with information without specialized
+and complex language parsers (take a look at <code>languages/python</code> that have a very simple python parser) but your language support will surely benefit
+from having such. There is a hand-written c/c++ parser (<code>lib/cppparser</code>) in KDevelop that might be used for ObjC or related C-based languages.
+
+Other (not so complex as c++) languages can be parsed by ANTLR based parsers (library is in lib/antlr).
+Consult www.antlr.org for a ANTLR documentation and look at <code>languages/java</code>, <code>languages/ada</code> and <code>languages/pascal</code> for an example of using such parsers.
+The latest version of ANTLR (2.7.2) has support for Java, C, Pascal, Ada, C++, CIM, HTML, IDL, Verilog, VRML, OCL, ASN.1, and SQL. You can write an ANTLR parser for your own language, of course.
+
+\subsection sectionClassStore Class store
+
+If you write (or have) a language parser, your language support can have
+"class store" (a database containing the information about scopes, classes
+and methods - their names, names of source files, location in source files,
+etc.). Class store libraries can be found at <code>lib/catalog</code> (Catalog) and <code>lib/interfaces</code> (CodeModel).
+
+KDevelop provides class browsers that extract information from a <b>class store</b> and display it in a tree view and toolbar selectors of scopes, classes and methods.
+
+\subsubsection sectionMemoryClassStore Memory class store
+CodeModel is the memory class store. It is very efficient and thus it is recommended for using as a project class store. CodeModel libraries are located in <code>lib/interfaces/codemodel.h</code>. The class browser for a CodeModel based stores is <code>parts/classview</code>.
+
+\subsubsection sectionPersistantClassStore Persistant class store
+Catalog is the persistant class store for KDevelop. Persistant class store can be used as an information storage for code completion but it also can be used as a class store for the project. Take a look at
+<code>languages/cpp</code> for an example of using catalog. Catalog is stored on disk in the database file (Berkeley db) If you use catalog with the project, your class browser will be <code>parts/classbrowser</code>.
+
+\subsection sectionCodeCompletion Code completion
+Class store enables you to write a code completion for the language. At the
+moment (2003-06-25), code completion is available only to cpp so take a
+look at it for an example.
+
+\subsection sectionProblemReporter Problem reporter
+
+If you have a language parser, you can implement <b>problem reporter</b>
+functionality for your language. The problem reporter catches errors
+reported by a parser and displays it in a problem reporter view.
+<code>languages/java</code>, <code>languages/ada</code>, <code>languages/pascal</code> and <code>languages/cpp</code> have problem reporters.
+
+\subsection sectionTemplates Templates
+
+\subsubsection sectionApplicationTemplates Application templates
+
+<b>Application wizard</b> templates should be also written. Appwizard templates are simple to create - consult \ref howToAddApplicationTemplates (HowToAddApplicationTemplates.dox file)
+and look at <code>languages/ruby/app_templates/rubyhello</code>, <code>languages/pascal/app_templates/pascalhello</code>, or <code>languages/ada/app_templates/adahello</code>.
+
+\subsubsection sectionApplicationImportTemplates Application import templates
+
+KDevelop has the ability to <b>create a new project from existing projects or source code</b>.
+It scans for project files ('*.kdevelop, *.kdevprj, *.studio, *.pro) and if
+  - it finds a project it extracts the necessary information
+  - it does not find project files it scans for source files (*.cpp, *.java, *.pl, *.py, ...)
+  .
+and creates a new KDevelop project in the direcotry the user has chosen.
+
+\subsubsection sectionSourceFileTemplates Source file templates
+
+Another thing to do is to create <b>file create templates</b>. They are prototypes for a source files of your language. These prototypes are placed in
+<code>parts/filecreate/file-templates</code> dir or <code>languages/YOURLANGUAGE/file_templates</code> and have names equal to the extensions of language source files.
+The description of the prototypes is placed in <code>parts/filecreate/template-info.xml</code>.
+
+Consult FileCreatePart (parts/filecreate/README.dox file) and \ref howToAddFileTemplates for further information.
+
+\subsubsection sectionAbbreviationTemplates Code abbreviation templates
+
+KDevelop has a support for <b>code abbreviations</b> so you can add some predefined abbreviations to your language support. Take <code>languages/cpp/cpptemplates</code> as an example.
+
+
+\subsection sectionSourceCodeFormater Source code formater
+
+Implement a KDevSourceFormater class interface.
+To obtain source formater functionality (that is already available to
+c-based languages) you can extend astyle library (<code>lib/astyle</code>) that is used by KDevelop to format sources.
+Take a look at AStylePart for an example how to do it.
+
+\subsection sectionDocumentationTopics Documentation topics
+
+Add them to <code>languages/YOURLANGUAGE/doc</code>. For an example see <code>languages/python/doc/python.toc</code> and <code>languages/python/doc/python.index</code>
+In the end you need to edit the <code>languages/YOURLANGUAGE/doc/Makefile.am</code> file to include the .toc and/or .index file.
+
+\subsection sectionDebugger Debugger
+
+The last thing to have a complete language support in KDevelop is to
+write a <b>Debugger </b>. KDevelop already provides GDB support
+(<code>languages/cpp/debugger</code>) and JDB (java debugger) support (<code>languages/java/debugger</code>). Take a look at them to get inspiration.
+
+\subsection sectionCompilerPlugins Compiler plugins
+
+There is an ability to create compiler plugin for KDevelop. Compiler plugin provides the compiler configuration dialog which implements command line compiler options.
+Compiler plugins must implement KDevCompilerOptions interface.
+
+
+\section MiscInf Other Info
+
+In the end you should add the language you implemented to the doc/api/LangSupportStatus.dox file and
+document your language support part in the way described at \ref howToDocument (doc/api/HowToDocument.dox file).
+See also \ref howToAddPlugins (doc/api/HowToAddPlugins.dox file) for an information on how to create a generic KDevelop plugin and how to manage project and global configuration information.
+
+
+
+
+
+\section sectionEditor Language Editor
+
+To edit source files KDevelop uses any editor that supports the KTextEditor
+interface. The current supported editors and their features are listed
+in the \ref EditorsSupportStatus (doc/api/EditorsSupportStatus.dox file) page.
+
+In case none of the editors does support advanced editing of sources
+written in your language (like code folding, syntax highlighting, line
+indentation) you can improve QEditor included in KDevelop (<code>editors/qeditor</code>).
+By creating QEditorIndenter and QSourceColorizer descendants you can provide the support for an automatic indentation and syntax highlighting that will be available for sure in KDevelop.
+
+
+
+
+
+
+\section sectionBuildTool Build Tool
+
+The language support is important, but it is unusable without a <b>build tool</b>
+that can manage projects written on this language. KDevelop
+currently provides several build tools. They are:
+
+  - ANT build tool
+    - see AntProjectPart at <code>buildtools/ant</code>
+    .
+  - Autotools build tool
+    - see AutoProjectPart at <code>buildtools/autotools</code>
+    .
+  - Custom build tool
+    - see CustomProjectPart at <code>buildtools/custommakefiles</code>
+    - (works with custom makefiles, also has ant support)
+    .
+  - Generic build tool
+    - see GenericProjectPart at <code>buildtools/generic</code>
+    - Offers build tool facilities using project files in xml format (dtd is located in <code>buildtools/generic/kdevxmlproject.dtd</code>).
+      Those xml files can be converted into makefiles, ant xml files or simply shell scripts using build system plugins.
+      Build system plugin is an object that implements KDevBuildSystem interface. Build system plugins are located in <code>buildtools/generic/buildsystem</code>.
+    .
+  - QMake build tool
+    - see TrollProjectPart at <code>buildtools/qmake</code>
+    .
+  .
+
+Also available:
+  - Script build tool
+    - <code>buildtools/script</code>
+    - (the generic build tool for all scripting languages).
+    .
+  - <code>buildtools/pascal</code> and
+  - <code>buildtools/ada</code>
+  - <code>buildtools/haskell</code>
+  .
+
+(They are deprecated build tools that will be replaced with the generic build tool).
+
+Choose your build tool and if the existing build tools doesn't fit
+in, extend generic build tool via build system plugin. \ref howToAddGenericBuildTools page (doc/api/HowToAddGenericBuildTools.dox file) helps you to do it.
+
+
+*/
diff --git a/doc/api/HowToDocument.dox b/doc/api/HowToDocument.dox
new file mode 100644
index 00000000..d606a8bf
--- /dev/null
+++ b/doc/api/HowToDocument.dox
@@ -0,0 +1,39 @@
+/** \file HowToDocument.dox
+  * \brief How to document KDevelop parts
+  */
+/** \page howToDocument How to document KDevelop parts
+
+You should add a README and a README.dox file to your part (KDevPlugin).
+
+On the README file put this text:
+\verbatim
+Please read the on-line, automaticaly updated KDevelop API documentation at:
+http://www.kdevelop.org
+or read the README.dox file.
+\endverbatim
+
+On the README.dox file put the mandatory information:
+\verbatim
+/** \class yourPartClassName
+Put a brief description here, the brief description ends at the first dot.
+Put a more detailed description of your part in these lines. It can span
+over several lines. You can even use some html commands in these lines like:
+<code>This is code</code>, html links <a href="http://somelocation">link text</a>,
+and images.
+
+...
+
+/*
+\endverbatim
+
+<b>IMPORTANT:</b> You should replace <code>yourPartClassName</code> with the name of the class that
+implements your part.
+
+On the area marked with <code>...</code> you can add optional informations. Here is an example of that:
+
+\verbinclude languages/cpp/app_templates/kdevpart/README.dox
+
+All these infos are optional and you should only add the link to the bugzilla database if YOUR_COMPONENT_NAME
+has been defined in that database.
+
+*/
diff --git a/doc/api/LangSupportStatus.dox b/doc/api/LangSupportStatus.dox
new file mode 100644
index 00000000..fa08cc67
--- /dev/null
+++ b/doc/api/LangSupportStatus.dox
@@ -0,0 +1,330 @@
+/** \file LangSupportStatus.dox
+  * \brief Programming Languages Support Status
+  */
+
+/** \page LangSupportStatus Programming Languages Support Status
+
+\ref howToAddProgrammingLanguages (doc/api/HowToAddProgrammingLanguages.dox file) for step by step info on how to implement these features.
+
+<table border="1">
+    <tr>
+      <th scope=col>Feature/Language</th>
+      <th scope=col><a href="classAdaSupportPart.html">Ada</a></th>
+      <th scope=col><a href="classBashSupportPart.html">Bash</a></th>
+      <th scope=col><a href="classCppSupportPart.html">C/C++</a></th>
+      <th scope=col><a href="classFortranSupportPart.html">Fortran</a></th>
+      <th scope=col><a href="classHaskellSupportPart.html">Haskell</a></th>
+      <th scope=col><a href="classJavaSupportPart.html">Java</a></th>
+      <th scope=col><a href="classPascalSupportPart.html">Pascal</a></th>
+      <th scope=col><a href="classPerlSupportPart.html">Perl</a></th>
+      <th scope=col><a href="classPHPSupportPart.html">PHP</a></th>
+      <th scope=col><a href="classPythonSupportPart.html">Python</a></th>
+      <th scope=col><a href="classRubySupportPart.html">Ruby</a></th>
+      <th scope=col><a href="classSQLSupportPart.html">SQL</a></th>
+    </tr>
+    <tr>
+      <td>\ref sectionClassWizard</td>
+      <td bgcolor="cyan">Y</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">N/A</td>
+    </tr>
+    <tr>
+      <td>\ref sectionAttributeMethodWizard</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">N/A</td>
+    </tr>
+    <tr>
+      <td>\ref sectionQtUiSubclassing</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="yellow">Y</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="green">N/A</td>
+    </tr>
+    <tr>
+      <td>  </td>
+    </tr>
+    <tr>
+      <td>\ref sectionLanguageParser</td>
+      <td bgcolor="green">ANTLR</td>
+      <td bgcolor="yellow">Internal</td>
+      <td bgcolor="green">cppparser</td>
+      <td bgcolor="yellow">Internal</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">ANTLR</td>
+      <td bgcolor="yellow">ANTLR</td>
+      <td bgcolor="yellow">Internal</td>
+      <td bgcolor="yellow">Internal</td>
+      <td bgcolor="yellow">Internal</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+    </tr>
+    <tr>
+      <td>\ref sectionMemoryClassStore</td>
+      <td bgcolor="cyan">CodeModel</td>
+      <td bgcolor="green">CodeModel</td>
+      <td bgcolor="green">CodeModel</td>
+      <td bgcolor="green">CodeModel</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="yellow">CodeModel</td>
+      <td bgcolor="cyan">CodeModel</td>
+      <td bgcolor="green">CodeModel</td>
+      <td bgcolor="green">CodeModel</td>
+      <td bgcolor="green">CodeModel</td>
+      <td bgcolor="green">N</td>
+      <td bgcolor="green">Y</td>
+    </tr>
+    <tr>
+      <td>\ref sectionPersistantClassStore</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Catalog</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">N/A</td>
+    </tr>
+    <tr>
+      <td>\ref sectionCodeCompletion</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="cyan">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+    </tr>
+    <tr>
+      <td>\ref sectionProblemReporter</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="yellow">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+    </tr>
+    <tr>
+      <td>  </td>
+    </tr>
+    <tr>
+      <td>\ref sectionApplicationTemplates</td>
+      <td bgcolor="yellow">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="yellow">Y</td>
+    </tr>
+    <tr>
+      <td>\ref sectionApplicationImportTemplates</td>
+      <td bgcolor="yellow">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+    </tr>
+    <tr>
+      <td>\ref sectionSourceFileTemplates</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="yellow">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+    </tr>
+    <tr>
+      <td>\ref sectionAbbreviationTemplates</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="yellow">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+    </tr>
+    <tr>
+      <td>\ref sectionSourceCodeFormater</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+    </tr>
+    <tr>
+      <td>  </td>
+    </tr>
+    <tr>
+      <td>\ref sectionDocumentationTopics</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="yellow">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="cyan">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+    </tr>
+    <tr>
+      <td>  </td>
+    </tr>
+    <tr>
+      <td>\ref sectionDebugger</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="yellow">Y</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">N</td>
+      <td bgcolor="red">N</td>
+    </tr>
+    <tr>
+      <td>\ref sectionCompilerPlugins</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">N/A</td>
+      <td bgcolor="green">gcc</td>
+      <td bgcolor="green">PGHPF, PGF77</td>
+      <td bgcolor="green">Glasgow</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="green">Delphi, Free Pascal</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+      <td bgcolor="red">N</td>
+    </tr>
+</table>
+<br>
+Legend:
+<br>
+<table>
+    <tr>
+      <td bgcolor="red"></td>
+      <td>Feature has not been implemented</td>
+    </tr>
+    <tr>
+      <td bgcolor="cyan"></td>
+      <td>Feature is in alpha state, the development has only been started or the feature is turned off at the moment</td>
+    </tr>
+    <tr>
+      <td bgcolor="yellow"></td>
+      <td>Feature is in beta state or it is unfinished</td>
+    </tr>
+    <tr>
+      <td bgcolor="green"></td>
+      <td>Feature is considered to be complete or complete enough for the release</td>
+    </tr>
+    <tr>
+      <td>N/A</td>
+      <td>Feature is not applicable for given language</td>
+    </tr>
+    <tr>
+      <td>Sourceinfo</td>
+      <td>Deprecated class store that should be replaced by a CodeModel
+      <br>Features implemented with Sourceinfo should not be marked as complete</td>
+    </tr>
+    <tr>
+      <td>CodeModel</td>
+      <td>New memory class store</td>
+    </tr>
+    <tr>
+      <td>Catalog</td>
+      <td>New persistant class store using Berkeley DB storage backend</td>
+    </tr>
+    <tr>
+      <td>ANTLR</td>
+      <td>Language parser is generated by ANTLR parser generator, http://www.antlr.org</td>
+    </tr>
+    <tr>
+      <td>cppparser</td>
+      <td>New c/c++ parser written by Roberto Raggi for KDevelop</td>
+    </tr>
+    <tr>
+      <td>Internal</td>
+      <td>Language parser is included in language support part</td>
+    </tr>
+</table>
+
+*/
+
diff --git a/doc/api/Mainpage.dox b/doc/api/Mainpage.dox
new file mode 100644
index 00000000..9d4b6d4c
--- /dev/null
+++ b/doc/api/Mainpage.dox
@@ -0,0 +1,91 @@
+/** \file Mainpage.dox
+    \brief The main page of the doxygen generated %API Documentation
+*/
+
+/**
+\mainpage The KDevelop %API %Documentation
+
+KDevelop is an easy to use IDE (Integrated Development Environment) for developing applications under X11.
+
+\section intro Introduction
+
+This document is targeted at all those that want to add or improve KDevelop's source code.
+If you are instead looking for a user manual, just go to the help menu of your KDevelop and select KDevelop handbook.
+This documentation contains the KDevelop online class reference for the current
+development version of KDevelop.  Additionally, you
+can subscribe or read the <a href="http://www.kdevelop.org/index.html?filename=mailinglist.html">mailing list</a> for any additions and/or
+modifications to the %API.
+
+An on-line, updated every 24H, html version of this documentation can be found at: http://www.kdevelop.org/HEAD/doc/api/html/index.html
+
+More information about the KDevelop architecture in form of tutorials, HOWTOs,
+and FAQs can be found at
+the <a href="http://www.kdevelop.org">KDevelop website</a>.
+
+
+\section status Current Status
+
+Here you can see the current \ref requirements and the \ref features.
+There is also a \ref LangSupportStatus (doc/api/LangSupportStatus.dox file) page and a \ref EditorsSupportStatus (doc/api/EditorsSupportStatus.dox file) page.
+
+
+\section expand How to expand KDevelop
+
+First of all read the \ref architecture (doc/api/Architecture.dox file) then you can find more information on how to expand KDevelop:
+  - \ref howToAddPlugins (doc/api/HowToAddPlugins.dox file)
+  - \ref howToAddProgrammingLanguages (doc/api/HowToAddProgrammingLanguages.dox file)
+  - \ref howToAddApplicationTemplates (doc/api/HowToAddApplicationTemplates.dox file)
+  - \ref howToAddFileTemplates (doc/api/HowToAddFileTemplates.dox file)
+  - \ref howToAddGenericBuildTools (doc/api/HowToAddGenericBuildTools.dox file)
+
+Additionally you may also want to find out \ref howToDocument (doc/api/HowToDocument.dox file).
+
+\section PlannedTasks Planned tasks
+
+Here is a priority ordered list:
+  -# \ref HighPriTasks (doc/api/HighPriTasks.dox file)
+  -# fix the dispersed \ref fixme
+  -# <a href="http://bugs.kde.org/buglist.cgi?product=kdevelop&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&order=bugs.bug_id">reported bugs in bugzilla database</a>
+  -# fix the bugs in the \ref bug
+  -# fix the dispersed \ref todo all over the code.
+  .
+There are some \ref unmaintained parts in KDevelop. You migth want to "adopt" one. :)\n
+There is also \ref FutureTasks (doc/api/FutureTasks.dox file). Put all ideas for the future KDevelop releases there. It is also a good place to comment on those ideas.
+
+\section misc Misc
+
+  - \ref authors
+  - \ref maintainers
+  - \ref FAQ
+  - \ref deprecated
+
+\section misc_libs Miscellaneous libraries included in KDevelop
+  - \ref PropEditor
+
+\section howTobuildAPIlocalcopy How to build a local copy of this documentation
+
+This documentation is very large and changes with every cvs commit, therefore is not available for download.
+To build your local copy of this documentation you have two choices, depending on your system configuration.
+  - If you have doxygen >= 1.3.4 , PHP >= 4.10 and a local running webserver then
+    - make apidox
+    - make install-apidox (as root)
+    .
+  - If you have an older system then
+    - setenv KDEDIR=/location_of_your_kde_instalation
+    - setenv QTDIR=/location_of_your_qt_instalation
+    - doxygen Doxyfile
+    - make install-apidox (as root)
+    .
+  .
+
+The advantage of the first method is that you'll get a search engine in your documentation if you read your
+documentation using your local webserver.
+
+\section License
+
+Permission is granted to copy, distribute and/or modify this document under
+the terms of the GNU Free %Documentation License, Version 1.2 or any later
+version published by the Free Software Foundation; For details see
+http://www.gnu.org/copyleft/fdl.html .
+
+*/
diff --git a/doc/api/PropEditor.dox b/doc/api/PropEditor.dox
new file mode 100644
index 00000000..b4f4eccc
--- /dev/null
+++ b/doc/api/PropEditor.dox
@@ -0,0 +1,108 @@
+/** \file PropEditor.dox
+    \brief The KDevelop Property Editor library description page
+*/
+
+/** \page PropEditor KDevelop Property Editor library description
+
+\section whatis What is Property Editor?
+
+%Property editor is a collection of facilities to store and edit the
+properties of an object. For example, look at %Qt Designer. Each widget
+has a list of properties that can be edited in a nice table form.
+Same ideology is used to edit properties in Kugar Report Designer
+(from KOffice distribution). In KDevelop project manager can also display
+the properties of currently selected build item in property editor.
+
+\section over Library Overview
+
+This PropertyEditor library is a redesign of Kugar property editing library 
+with the goal to be more generic and extensible.
+
+Library provides a @ref PropertyLib::Property class which stores property name, value and some
+more important information like description or the list of possible values.
+Using @ref PropertyLib::Property class adds more overhead over Q_PROPERTY but provides more
+flexibility. You can subclass @ref PropertyLib::Property and create your custom properties.
+Custom properties can have either predefined type (see @ref PropertyLib::PropertyType) or
+custom type. Custom type should be used if a custom property editor widget is
+necessary.
+
+Properties are organized into lists. @ref PropertyLib::PropertyList is designed
+to store such lists in most efficient manner. It also allows to group
+properties (for example think about "geometrical" properties like "x", "y", etc.).
+
+Property lists can be displayed in @ref PropertyLib::PropertyEditor widget which will
+display them in a table form. Note that @ref PropertyLib::PropertyEditor takes not
+a @ref PropertyLib::PropertyList object, but @ref PropertyLib::PropertyAccessor instead.
+
+@ref PropertyLib::PropertyAccessor is designed to provide a method to access an intersection
+of property lists. For example, let's consider object A with property list a_list
+abd object B with list b_list. Now let's imagine we want to display common properties
+from a_list and b_list in one @ref PropertyLib::PropertyEditor widget. Obviously, we need to
+"intersect" a_list with b_list and display the result of intersection.
+This is why @ref PropertyLib::PropertyAccessor is used for editing. If we change
+the value of a property in the editor, @ref PropertyLib::PropertyAccessor will update
+both properties from underlying a_list and b_list.
+
+@ref PropertyLib::PropertyEditor at the same time shows only one editor for selected
+property in the list. Each @ref PropertyLib::PropertyType has corresponding @ref PropertyLib::PropertyWidget
+which displays property editor or draws a property in the list if it is not edited.
+More exactly, if @ref PropertyLib::PropertyEditor needs to display editor widget, it displays
+@ref PropertyLib::PropertyWidget, else it calls @ref PropertyLib::PropertyWidget::drawViewer function.
+Custom property widgets should be subclasses of @ref PropertyLib::PropertyWidget.
+
+To create property widgets at runtime, a factory is used. Factory class is
+called @ref PropertyLib::PropertyMachineFactory. Static function @ref PropertyLib::PropertyMachineFactory::getInstance
+can be used to obtain the reference to the factory instance. Factory creates and returns
+so-called @ref Machine for each registered property type (either predefined or user defined).
+
+@ref Machine contains @ref PropertyLib::PropertyWidget and a list of "detailed" machines.
+Usually only property widget is necessary for a property but there are 
+complex properties like "Font" for example. We would like to see separate editors
+for font family, size, etc. and a button to choose all of these in the dialog.
+For that "Font" property, a PropertyWidget with a "choose font" button 
+and also number of detailed widgets like "font family" combo, etc. can be created.
+
+\section Examples
+A simple example on how to create a property editor and use it with one property list:
+\code
+    PropertyEditor *m_editor = new PropertyEditor(this);
+    
+    PropertyList *list = new PropertyList;
+    list->addProperty("My Group", new Property(Integer, "First Property",
+        "This is my first property", -5));
+    list->addProperty("My Group", new Property(String, "Second Property",
+        "This is my second property", "Hello"));
+    list->addProperty(new Property(Color, "Third Property",
+        "This is my third property", QColor("green")));
+        
+    m_editor->populateProperties(*list);
+\endcode
+
+More advanced example with property accessors and list intersection:
+\code
+    PropertyEditor *m_editor = new PropertyEditor(this);
+    
+    PropertyList *list = new PropertyList;
+    list->addProperty("My Group", new Property(Integer, "First Property",
+        "This is my first property", -5));
+    list->addProperty("My Group", new Property(String, "Second Property",
+        "This is my second property", "Hello"));
+    list->addProperty(new Property(Color, "Third Property",
+        "This is my third property", QColor("green")));
+
+    PropertyList *list2 = new PropertyList;
+    list2->addProperty("My Group", new Property(Integer, "First Property",
+        "This is my first property", -7));
+    list2->addProperty("My Group", new Property(String, "Second Property",
+        "This is my second property", "Hello"));
+    list2->addProperty(new Property(String, "Third Property",
+        "This is my third property", "green"));
+
+    PropertyAccessor *ac = list->intersect(*list2);
+    
+    m_editor->populateProperties(ac);
+\endcode
+In this example only properties named "First Property" and "Second Property" will be shown in editor.
+"Third Property" has different types in list and list2 and will not be included in intersection. 
+
+*/
diff --git a/doc/api/propeditor1.png b/doc/api/propeditor1.png
new file mode 100644
index 00000000..854b91f6
--- /dev/null
+++ b/doc/api/propeditor1.png
diff --git a/doc/api/propeditor2.png b/doc/api/propeditor2.png
new file mode 100644
index 00000000..66f8a75b
--- /dev/null
+++ b/doc/api/propeditor2.png