List of things to have "complete" support of a given language in TDevelop
- Implement interface KDevLanguageSupport
- Class wizard
- Attribute/Method wizard
- Qt UI subclassing - (if the language has Qt bindings)
- Language parser
- Class store
- Code completion
- Problem reporter - (parses source on the fly and reports syntax errors)
- Templates
- Application templates
- Application import templates
- Source file templates
- Code abbreviation templates - (ife expands to an if else statement, etc)
- Source code formater (prettyprint functionality)
- Documentation topics
- Debugger
- (gdb/jdb/??? integration)
- Compiler plugins
List of optional things to support a given language in TDevelop:
- Language Editor - Syntax highlighter - (add to QEditor if not available elsewhere)
- Build Tool (make/ant/etc)
Take a look at Programming Languages Support Status (doc/api/LangSupportStatus.dox file) to see the current status/features of the programming languages currently supported by TDevelop.
Language Support
Any language support should be written as a tdevelop part and implement KDevLanguageSupport interface (lib/interfaces/kdevlanguagesupport.h
).
Implementing methods:
virtual Features features();
virtual KMimeType::List mimeTypes();
Should be enough for a language support to start working.
TDevelop ships with KDevLang project template. It is a simple language support prototype that can be used when developing language support plugins with TDevelop. To use it, start a New Project and select: C++->TDevelop->TDevelop Language Support Plugin
in the application wizard. The template is located in languages/cpp/app_templates/kdevlang
, you can change it there if you need.
You should look at languages/ruby
for a simple language support implementation. For a compilable language support, consult languages/ada
or languages/pascal
(they are not so complex as languages/cpp
).
Pascal would be a good starting place, as it is the smaller of the two by far.
Language support can offer additional features:
Class wizard
- new class wizard: (See
ada, php, cpp
orjava
)virtual void addClass();
Attribute/Method wizard
- add method dialog: (See
cpp
orjava
)virtual void addMethod(const QString &className);
- add attribute dialog: (See
cpp
orjava
)virtual void addAttribute(const QString &className);
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:
virtual QStringList subclassWidget(const QString& formName);
virtual QStringList updateWidget(const QString& formName, const QString& fileName);
See cpp
and java
for examples.
Language parser
In general, class stores can be filled with information without specialized and complex language parsers (take a look at languages/python
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 (lib/cppparser
) in TDevelop 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 languages/java
, languages/ada
and languages/pascal
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.
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 lib/catalog
(Catalog) and lib/interfaces
(CodeModel).
TDevelop provides class browsers that extract information from a class store and display it in a tree view and toolbar selectors of scopes, classes and methods.
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 lib/interfaces/codemodel.h
. The class browser for a CodeModel based stores is parts/classview
.
Persistant class store
Catalog is the persistant class store for TDevelop. 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 languages/cpp
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 parts/classbrowser
.
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.
Problem reporter
If you have a language parser, you can implement problem reporter functionality for your language. The problem reporter catches errors reported by a parser and displays it in a problem reporter view. languages/java
, languages/ada
, languages/pascal
and languages/cpp
have problem reporters.
Templates
Application templates
Application wizard templates should be also written. Appwizard templates are simple to create - consult How to add application templates to the application wizard part (HowToAddApplicationTemplates.dox file) and look at languages/ruby/app_templates/rubyhello
, languages/pascal/app_templates/pascalhello
, or languages/ada/app_templates/adahello
.
Application import templates
TDevelop has the ability to create a new project from existing projects or source code. 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 TDevelop project in the direcotry the user has chosen.
Source file templates
Another thing to do is to create file create templates. They are prototypes for a source files of your language. These prototypes are placed in parts/filecreate/file-templates
dir or languages/YOURLANGUAGE/file_templates
and have names equal to the extensions of language source files. The description of the prototypes is placed in parts/filecreate/template-info.xml
.
Consult FileCreatePart (parts/filecreate/README.dox file) and How to add file templates to the file create part for further information.
Code abbreviation templates
TDevelop has a support for code abbreviations so you can add some predefined abbreviations to your language support. Take languages/cpp/cpptemplates
as an example.
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 (lib/astyle
) that is used by TDevelop to format sources. Take a look at AStylePart for an example how to do it.
Documentation topics
Add them to languages/YOURLANGUAGE/doc
. For an example see languages/python/doc/python.toc
and languages/python/doc/python.index
In the end you need to edit the languages/YOURLANGUAGE/doc/Makefile.am
file to include the .toc and/or .index file.
Debugger
The last thing to have a complete language support in TDevelop is to write a Debugger . TDevelop already provides GDB support (languages/cpp/debugger
) and JDB (java debugger) support (languages/java/debugger
). Take a look at them to get inspiration.
Compiler plugins
There is an ability to create compiler plugin for TDevelop. Compiler plugin provides the compiler configuration dialog which implements command line compiler options. Compiler plugins must implement KDevCompilerOptions interface.
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 How to document TDevelop parts (doc/api/HowToDocument.dox file). See also How to extend TDevelop via plugins (doc/api/HowToAddPlugins.dox file) for an information on how to create a generic TDevelop plugin and how to manage project and global configuration information.
Language Editor
To edit source files TDevelop uses any editor that supports the KTextEditor interface. The current supported editors and their features are listed in the Editors Support Status (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 TDevelop (editors/qeditor
). 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 TDevelop.
Build Tool
The language support is important, but it is unusable without a build tool that can manage projects written on this language. TDevelop currently provides several build tools. They are:
- ANT build tool
- see AntProjectPart at
buildtools/ant
- see AntProjectPart at
- Autotools build tool
- see AutoProjectPart at
buildtools/autotools
- see AutoProjectPart at
- Custom build tool
- see CustomProjectPart at
buildtools/custommakefiles
- (works with custom makefiles, also has ant support)
- see CustomProjectPart at
- Generic build tool
- see GenericProjectPart at
buildtools/generic
- 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 inbuildtools/generic/buildsystem
.
- see GenericProjectPart at
- QMake build tool
- see TrollProjectPart at
buildtools/qmake
- see TrollProjectPart at
Also available:
- Script build tool
buildtools/script
- (the generic build tool for all scripting languages).
buildtools/pascal
andbuildtools/ada
buildtools/haskell
(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. How to add a generic build tool plugins to the generic build tool part page (doc/api/HowToAddGenericBuildTools.dox file) helps you to do it.