APIdocs

wxDevIDE Internals Planning

by Esteban Aguilar

Another api page to look at: [EditorApi] This is an in-depth page on the editor plugin api and structure.

This is an informal-draft-proposal on the internals of future wxDevIDE; a "quick" description, so we can start the discussion, and start talking about specific things, and also to distribute some of the work among the developers. I've had some hard time trying to explain myself, so don't freak out if you think I make no sense; you could be right, but it could also be that I did a poor job explaining.

A. From the point of view of the UI, the IDE is the host (supported by wxAUI or equivalent) for the following components:
* Toolbar hosting dock (can host groups of buttons, comboboxes, text fiels...).
* Left, right (preffered for properties and tree-view panels) and bottom (preferred for message panels) docks.
* Center tabbed panel for editors.
* Menu items
Most of the default instances of these components should be "pluggable", except perhaps some menu entries and toolbars.

At the core of the application, a "MainController" class should manage the communication and state of those pluggable components or plugins.

In this context, "pluggable" means that all the messaging between the IDE and the components is done through interfaces (in our case, C++ abstract classes), which could be statically or dynamically loaded. So, the services exposed from the MainController to these components are described in some interface, and all these components implement other interfaces on their own, which the MainController recognizes.

B. A plugin can do more or less the following things:
1. Run arbitrary code, as long as there is little to no interaction with the IDE components, after being invoked from the following scenarios:

• Plugin creation:
• One of the event notifications broadcasted to active plugins.

• From within the plugin self visual components embedded on the IDE: Toolbar buttons, menu entries, or window, panels events.

• Run code that interacts with the predefined APIs of the IDE, invoking predefined actions that are relevant to wxDevIDE's tasks.

• Run code that interacts with the predefined APIs of other plugins, on wich they depend.
  Addressing the second type above, we'll call this specific type of plugin: "Profile Plugin". These are series of components that can be loaded within the IDE and that address a specific Profile type (more or less like current Project types), in order to provide specific functionality. For example, giving the IDE features for C++ development (designing, editing, compiling...).
  A Profile (or Project template file) associates a given group of files to a [wiki:ProP "Profile Plugin"] (ProP for short, on this document).

C. A ProP can contain:

• Menu entries
• Toolbar components
• Dockable panels
• Editors
• Compilers, debuggers
• Non IDE embedded Dialogs
• logic

There are 2 "facets" in a ProP that can be implemented independently or together in a single ProP, and both can (and should) communicate through interfaces:

D. Let's say, the frontend is compound of (not necessarily all of them):
Menu entries
ToolBars
Editors
Panels
*logic

E. Let's call the other one backend (not necessarily all of them are required):
* Menu entries
* ToolBars
* Compilers, Debuggers, Assemblers, linkers, etc.
* logic

The justification for these frontend and backend concepts is that they represent plugable entities that can be implemented separately, and could work together on a single Profile. The differentiation here is that frontend stuff is for working on files through editors-designers (user interaction), while the backend things do automated work on the data.

Inside a Profile, specific file types can be associated with specific editors-panels-toolbar_buttons-menu_entries (a frontend) and/or specific compilers_linkers_etc-toolbar_buttons-menu_entries (a backend), according to the ProP rules. Each project type can be associated with a specific ProP, using the project template.

F. To start describing some of the services related to ProPs, lets use the following list (needs to be extended):
For clarification, "Default" means the current IDE registered action (saved on config files), and "Active" means, the available action, based on the current context (for instance, when a specific Profile is active):

• There will be a "default" ProP and an "Active" ProP for a specific group of files (Profile) at any time. In practice, this means a user-experience more or less like this:

• The user creates or opens a workspace, then creates or opens a project; the project has an specific ProP associated with it, according to the project type used when creating it. So, that action invokes the ProP startup code. back end and frontend ProPs for this project type could be created separately; Single files also have ProPs associated with them, so even if a project opens with ProP "X", you can open a specific file of the project with another ProP, provided that it is registered for that file type. One example of this is opening a wxWidgets project, registered with our default wxdsgn designer, then opening one of the project files with an "OpenGL designer" (or whatever, is just an example) ProP plugin at the same time. However, multiple simultaneous plugins will only be available for front end ProPs, so it will not be possible to have 2 compiler plugins for files within the same project active at the same time. This separation of frontend and backend ProPs means that the backend stuff (compiler, debugger, linker) could be replaced for other one, and still use the same frontend components (designers, palletes, inspector panels) to edit the same project types (Profiles) and viceversa.

• There will be basic APIs (interface functions) that both backend and frontend ProPs need to implement. However, each ProP can expose their own APIs (public interfaces) for extensibility and their own controllers for communication between their components. So, for our default C++ compiler, debugger, designer etc, we will create a base class compiler, debugger, designer.. etc with interfaces, that can be used to replace these components with different versions. These APIs are less general than those provided by the IDE, since these are oriented to support C++ specific projects (and that's not the only goal for wxDevIDE). Each time we (or someone else) creates a new type of profile oriented plugins for projects not compatible (lets say, PHP projects, were there is no compilation, so back end components require a different meaning), they can set their own APIs for that type of profiles if they want to, so extensibility is "recursively extensible".

• "New File" button-menu entry: "Default" and "Active" actions. A plugin can override both actions.
• "Save File" button-menu entry: "Default" and "Active" actions. A plugin can override both actions.
• "Save All Files" button-menu entry: "Default" and "Active" actions. A plugin can override both actions.
• "File Navigator" pane: There will be an interface for this and a base file navigator, that implements this interface, and which plugins can inherit from.
• "Properties Inspector" pane: Properties can be populated from a plugin. There will be an interface for this and a base properties inspector, that implements this interface, and which plugins can inherit from.
• Editor (with Clipboard, undo, find, search, replace, .. etc functions): General editor methods. For the extensible ones we should take a look at CodeLite's plugin API and add some more methods if required. There will be an interface for this and a base editor, that implements this interface, and which plugins can inherit from.
• Overridable toolbar buttons and/or menu entries like add/remove from project, go to line, undo-redo, cut, copy, paste, close file.
• Compile, buld, rebuild, debug, and the like should be provided from a specific ProP, because depending on the project type, they could make sense or not. The exception to this could be "Execute", which may be a default overridable button as the previous ones.

G. Some portions of the wxDevIDE are not ProP focused, but still provide extensibility (some through type 1 of plugins from listing B.). We need to define which ones exactly. Some services/functionalities required in wxDevIDE:

• Plugin loading, unloading.
• Plugin visual components embedding-unembedding-enabling-disabling:
• Menu entries with their own actions
• Toolbar buttons or other controls with their own actions
• Custom Panels.
• "New Project" button-menu entry: Opens a dialog that lists all projects types based on a set of registered profiles, each one with a respective template. After choosing the selected project type, the respective ProP startup code will be invoked. This button action is static, but the list of available projects (templates) is extensible, from a package manager system.
• "Close project": notifies the respective ProP.
• "File Navigator" pane: Default contextual menu entries for nodes. Those entries can be added-removed from a plugin of any type.
• General dockable pane interface, with a base pane implementation, inheritable from plugins ("Base File Navigator" and "Base Properties Inspector" inherit from this too)
• IDE Drag and drop event notification broadcasting in all locations listed on point A.
• Status bar: text can be provided from a plugin.
• About dialog extensions (tabs or combobox entries could be added from plugins, to display specific credits, info).
• Access to specific tab-editor based on index and file name; opening, closing, or reordering.
• Current focused-active Editor (return name or editor).
• Current active group? (Editors related to a file or group of files, like .h, .cpp, .wxform or whatever) (return names of editors).
• General "File manager" base class, with file services, that components (ProPs or general plugins) can use. BaseEditor will contain one of these.
• Configuration settings storing on XML format (taking into account specific plugin settings on their own folders).
• Configuration settings loading-provider.

H. Other features:

• Decoupled Update management (similar to the current one).
• Package management (similar to the current one).
• Printing (similar or better than the current one).
• Workspaces.
• Recent files opened (similar to the current one).
• Tools management for external programs (similar to the current one).
• Window management and navigation.
• Toolbars management.
• Shortcuts.
• Help system (similar to current one).
• Register file types: File types will be associated with an specific ProP, or several.

Our distribution will deploy default frontend and backend components for C++. Maybe more than one frontends: a wxWidgets oriented (with designer), one for plain C++ projects.