summaryrefslogtreecommitdiffstats
path: root/doc/api
diff options
context:
space:
mode:
Diffstat (limited to 'doc/api')
-rw-r--r--doc/api/Architecture.dox315
-rw-r--r--doc/api/Architecture.pngbin0 -> 71707 bytes
-rw-r--r--doc/api/Architecture.sxdbin0 -> 7581 bytes
-rw-r--r--doc/api/Development.pngbin0 -> 71400 bytes
-rw-r--r--doc/api/Development.sxdbin0 -> 8396 bytes
-rw-r--r--doc/api/EditorsSupportStatus.dox189
-rw-r--r--doc/api/FutureTasks.dox136
-rw-r--r--doc/api/HighPriTasks.dox36
-rw-r--r--doc/api/HowToAddApplicationTemplates.dox285
-rw-r--r--doc/api/HowToAddFileTemplates.dox30
-rw-r--r--doc/api/HowToAddGenericBuildTools.dox21
-rw-r--r--doc/api/HowToAddPlugins.dox204
-rw-r--r--doc/api/HowToAddProgrammingLanguages.dox252
-rw-r--r--doc/api/HowToDocument.dox39
-rw-r--r--doc/api/LangSupportStatus.dox330
-rw-r--r--doc/api/Mainpage.dox91
-rw-r--r--doc/api/PropEditor.dox108
-rw-r--r--doc/api/propeditor1.pngbin0 -> 3937 bytes
-rw-r--r--doc/api/propeditor2.pngbin0 -> 3697 bytes
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
Binary files differ
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
Binary files differ
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
Binary files differ
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
Binary files differ
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
Binary files differ
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
Binary files differ
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-14 06:46:31 +0000