IDE

wxDevIDE will be more modular than Dev-C++ since it is being designed with plugins from the start. The text editor component will be a plugin to allow for replacements in the future or by user preference. Other parts of the ide will be sectioned out similarly, such as settings dialogs.

The basic layout of the IDE:
Main IDE window with the plugin manager attached. (to manage graphical element embedding)
The plugin manager handles activating and initializing all plugins based on user preferences and the compiler (build tools) in use.
The main window supports docking and floatable tool bars through AUI. The message pane at the bottom, main menu, a project panel on the left side.

Plugin system:
the core of the plugin system does the heavy lifting, the manager is an interface to it. It has several "sockets" for different types of plugins. These are called "master plugins". A master plugin contains all of the main dialogs like settings, variable watches, etc.. for its plugin type. Then an api for interacting with that dialog is supplied to plugins. This way the interface can remain consistent and only the plugins that deal with a specific portion of the IDE need to know about the interfaces. The master plugin supplies an appropriate interface for the type of plugins it supports, it uses the core to embed GUI elements into the main window of the ide and supplies all access interfaces to its dialogs and other necessary bits.

Master Plugins:
Editor, this has an editor settings similar to the Dev one. Syntax highlighting can be stored by the plugin however it prefers.
The various check box settings probably will be added via api in the master plugin to allow for different editors. The editor
can access the settings being stored to update its behavior.
Build Tools (compiler), This provides a settings dialog with some kind of multiple compiler support in the interface, It accesses the profiles in the project for build settings and the like. Some method to make the "project Settings" dialog aware of the appropriate settings and values must be implemented.
Debugger
Tools, these plugins only need a minimal GUI interface and no managed dialogs or resources are part of it. The tools can embed a menu or menu-item,
tool-elements or toolbar that can be used to access it. It supplies its own settings dialog if it needs one. Access to project settings, editor,
compiler settings, etc. It can do whatever essentially but handles all of its own work.
Versioning, because Dev came with CVS support this master is here. however instead of CVS only this manages a generic interface for versioning tools.
that way other tools such as SVN or GIT can be used at the users preference.
Addon, This is a more robust version of the tools master. It allows embedding in all of the GUI and gives it some access to event hooks as well. This is where the Designer would fit in.

The notebook control that will be used is MultiBook. XSTC (a wrapper for wxScitnilla/wxSTC) Is going to be the control for the editor plugin. AUI will be used for the toolbars and docking. wxWidgets of course for the development toolkit.

A few plugin ideas:
project file converter like C::B, MS, codelite
formatted source exporter to html, pdf, rtf....
highlighting spell checker (can be used from NZTextEditor)
javascript-ing support (can be used from NZTextEditor)
convert old dev projects to wxDev projects
various versioning support
astyle
doxygen
interactive terminal

Multiple compiler/language support:
In order to support several build-tools (compilers etc..) the plugin system will use some basic type info.
each plugin will have several string values describing it and what it is compatible with.
Language: the syntax/language it supports (C++)
Toolkit: build tools that the plugin is meant to be used with. (MINGW)
Name: of the plugin
Version: of the plugin

A special value "ANY" can be used with Language or Toolkit to tell the plugin manager that this plugin doesn't need to worry about it. If the plugin doesn't care about language syntax then Language would be set to ANY, same with toolkit where any toolkit of a specific language can be used. Setting both to ANY with leave the plugin on regardless of the build-tools in use, even if they are a completely different language.

The plugin manager will automatically check all registered plugins for the Language and Toolkit values and turn them on or off depending on compatibility. Also the user could tell the manager to disable a plugin in which case it would remain off in any case. The debugger will automatically change when the build-tools do, however if a debugger is capable of interacting with several of the build-tools executables, the user could tell the manager to set it up for those plugins. (this would be a manual override setting)

This section moved, the whole page needs some cleanup.

Code

wxDevIDE is written in C++ with the wxWidgets library. Source code is to be kept in a subversion (SVN) library. Before committing changes to SVN, developers will format their code using the AStyle tool and document their code using Doyxgen. Write access to the SVN is limited to project developers.

Architecture

wxDevIDE is a collection of distinct modules which interface via a central API. The central API uses wxAUI to manage the menu and dockable windows.

For more details, see the [APIdocs] for wxDevIDE internals.

Modules include:
* code editor
* code parser/completion
* compiler interface
* degugger interface
* rapid application designer (RAD)
* package manager

TODO: Are there other modules??

Each module is considered a separate project within the wxDevIDE workspace. Modules may be updated independently of other modules and may be superceded by custom modules. For example, a future developer may rewrite the code editor favoring one method over another (e.g. SynEdit over Scintilla). Under the terms of the license, custom modules may have their own licensing provided that it does not conflict with the wxDevIDE's license.

=== Code editor ===

The code editor module uses wxScintilla, a wrapper of the Scintilla edit control. As this is the primary visual interface with the user, a major requirement is that the editor have the same look and feel of the wxDevC++/Dev-C++ editor window.

The editor supports the standard features including:
* code styling
* code beautification
* syntax highlighting
* cut/copy/paste/delete
* undo/redo
* code folding
* search/replace
* bookmarking
* call tips
* keyboard shortcuts
* custom margins
* line wrapping
* macros
* printing
* brace highlighting

Workspace support is standard. Multiple windows may be open in source code editor simultaneously. The editor module keeps track of which windows have been altered and prompts the user to save the file if unsaved work is about to be lost.

Code parser/completion

The parser module scans the code displayed by the editor module and organizes it according to the standard tokens of the target language. This makes possible to display possible completions for functions and classes as the user is typing the program into the editor. For example, in wxDev-C++, the user may begin typing the code:

wxString::

and immediately a drop-down box appears listing the class/function prototypes for the wxString class.

Although wxDevIDE can be used to program in several computer languages, initial work on the parser will focus on the C/C++ language. An algorithm based on IComplete, a baccalaureate project authored by Martin Stubenschrott, is used to provide both code parsing and code completion (Stubenschrott, M. "A context sensitive code completion system for the C and C++ programming languages." Institut f¨ur Computersprachen an der Technischen Universit¨at Wien, April 2005). Exuberant-ctags is used as the primary lexer to analyze the code. It has parsing support for 25 programming languages. With C/C++ programs, it can generate tokens for:

• class names
• macro definitions
• enumeration names
• enumerators
• function definitions
• function prototypes/declarations
• class, interface, struct, and union data members
• structure names
• typedefs
• union names
• variables (definitions and external declarations)

The module uses exuberant-ctags to parse libraries and generate a SQLite database file of these tokens. As the user types his code into the editor, the database is continually searched for possible completion of these tokens and displays a dropdown box of suggestions.

Compiler interface

wxDevIDE supports two compilers natively: gcc and Microsoft Visual C++ (MSVC). However, the compiler interface module should be sufficiently generic to allow support for other compilers.

As with wxDev-C++/Dev-C++, GNU Make is used as the build tool for projects. It is able to build both gcc and MSVC projects, and it might be extended to other compilers as well. Makefiles include generous use of variables to help with code portability.

For example,

CPP       = g++.exe  
CC        = gcc.exe  
LINK      = g++.exe  
OBJ       = Objects/MingW/Project1App.o Objects/MingW/Project1Frm.o Objects/MingW/Project1_private.res  
LINKOBJ   = Objects/MingW/Project1App.o Objects/MingW/Project1Frm.o Objects/MingW/Project1_private.res  
LIBS      = -L"C:/Program Files/Dev-Cpp/Lib" -mwindows -lwxmsw28 -lwxmsw28_gl -lwxtiff -lwxjpeg -lwxpng -lwxzlib -lwxregex -lwxexpat -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lodbc32 -lopengl32    
DEFINES   = -D__WXMSW__ -D__GNUWIN32__ -D__WIN95__  
WXLIBNAME = wxmsw28

The module allows for both release and debug versions of the workspace. As with wxDev-C++, the compiler module allows for project templates, customizable compiler options, compiler output windows, and "on the fly" switching between compiler profiles. Environmental variables, such as placeholders for the library paths, should be supported to ensure portability.

The compiler options dialogs are constructed at runtime by reading an XML file within the IDE's settings directory (devCompilers.xml). This compiler configuration file contains the number of compilers, compiler names, options/switches, default settings, and regular expression (regex) templates for constructing the makefile based on that compiler. It should be a user-modifiable file to allow the user complete control over the compiler interface and output.

Debugger interface

The debugger module is an API interface which links to a standard, stand-alone debugger. We continue to use the GNU debugger (gdb) as the supported code debugger, however, the interface should be made as generic as possible to allow us to pass messages to and from other debuggers as well.

Rapid application designer (RAD)

The RAD module was the standout module for wxDev-C++ and continues to be the most important module for wxDevIDE. Official support is made for visual designing GUIs with wxWidgets. The module maintains an XML settings file for each supported widget. The XML file contains the widget properties and default code output.

In this way, if future GUI API libraries are supported (e.g. Qt), the XML files may be updated to support the change in calling syntax and widget properties. More importantly, if there are errors/changes in wxWidgets calling conventions, they can be easily corrected by the user without having to publish a new release.

Code generation is still performed using the "search and replace" method of wxDev-C++. Whenever the form is modified in the RAD, the code generation replaces all code between the comment bounds:

////GUI Items Creation Start  
...  
...  
Auto-generated code goes here  
...  
...  
////GUI Items Creation End

The .wxform format used in wxDev-C++ has been replaced with an XML file of the form. This may have the added benefit of allowing existing XRC projects to seamlessly import into the IDE (as they are based on XML definitions of the forms). A form migration wizard converts wxDev-C++ projects to the new format.

Return [Home]