This document is the roadmap for future development of anjuta.

Introduction:
-------------
Over the years, the anjuta codebase has exploded in size and complexity due to
the addition of a large number of features. The time has come to clean it up
before it is too late. Basicallt, we need to gradually move our codebase to
a more manageble level by refactoring.

Roughly, the idea is to divide the code into a shell and a set of components.
The shell should be a basic workable IDE along with a set of APIs which are
exposed so that components can be effectively written to extend the IDE.

Anjuta branches:
----------------
Anjuta currently has two main branches, ANJUTA_1_0_0 and HEAD. The ANJUTA_1_0_0
branch is for GNOME 1.x and is currently considered to be the stable branch. The
HEAD branch is used for GNOME 2.x and is currently in pre-alpha stage. However,
it is mostly usable and compiles and works on a standard GNOME 2.2 install, with
the added dependency for ZVT (slated to be replaced by VTE before 1.2.0)

About Anjuta2:
--------------
The said anjuta2 merge never happened, and seems unlikely to happen in the short
term. This is because the architectural differences between the projects is so
significant that moving code from one to another without an almost-total rewrite
is virtually impossible.

So, instead of dropping the anjuta codebase altogether, we should aim at
refactoring of the codebase by reusing the best bits of anjuta2, esp. the ideas
from the plugin architecture. However, this should be done in a way so that most
of the existing codebase can be reused, which is not possible with a complete
move to the anjuta2 framework.

If we can do this effectively and cleanly, it will be possible in the long term
to have more core reuse with the Anjuta2 project.

Branching proposal:
-------------------
It is proposed that HEAD be branched at this point to create a gnome-2-2 branch.
This branch should contain continued porting efforts and aim for an alpha release
somewhere in the soming month (April/May 2003). Mostly, remaining work consists
of:
	1. Porting stable branch fixes over to HEAD.
	2. Removing use fo deprecated widgets in message manager, etc.
	3. Stabilization and bugfixes.
	4. Wean away ZVT dependency from launcher.
	5. Adding other small demanded features.

Subsequent to this branch, HEAD should be used for code refactoring,
reorganization and gradual move to a new plugin based architecture.

Current source structure:
-------------------------
In the current codebase, there is no concept of a shell and most functionality
is implemented directory inside the main source (src) directory. Here is a
rough division of functionality vs. files in the current codebase:
	printing/: Printing support for the scintilla widget.
	scintilla/, src/aneditor.*, src/lexer.h, src/text_editor*.*,
	src/goto_line.*, : The scintilla editing component
	scintilla/Lex*.*: Lexers for scintilla (for highliting)
	src/anjuta*.*, src/mainmenu*.*, src/controls.*, src/toolbar*.*,
	src/resources.*, src/utilities.*, src/widget-registry.*, src/dnd.*,
	src/windows-dialog.*, src/about.*, src/compat*.*, src/getline.c,
	src/global.h, src/main.c, src/main_menubar*.*: Shell and utilities
	src/find*.*, src/search-replace.*: Search and replace
	plugins/, anjuta-plugins.*: A limited plugins system
	src/launcher.*, launcher/: Controlled command execution
	src/message*.*: Messages dockwindow at the bottom
	src/project*.*: Project management
	src/cvs*.*: CVS support
	src/debug*.*, src/breakpoints.*, src/watch*.*, src/attach*.*,
	src/memory.*, src/register*.*, src/sharedlib*.*, src/signals*.*:
	A gdb based debugger for C/C++ code.
	src/compiler*.*, src/clean_project.*, src/commands.*, src/executer.*,
	src/configurer.*: Build system
	src/session*.*: Session management
	src/properties*.*, scintilla/Prop*.*: Properties system.
	anjuta.glade: All dialogs GUI (designed using glade-2)
	manuals/: Manual, FAQ and tutotial.
	pixmaps/, src/pixmaps.h: All images
	scripts/: Some common scripts
	widgets/, src/fileselection.*: Custom widgets used by Anjuta
	tagmanager/, global-tags/: Tag (symbol) management backend.
	src/anjuta-tools.*: User-defined tools backend and GUI
	src/appwiz*.*, src/gnome_project.*, src/project_dbase.*, src/source.*,
	src/wizard*.*: Wizards for creating new projects.
	src/preferences*.*, src/defaults.*: Preferences system.
	src/an_file_view.*: A file tree viewer
	src/an_symbol_view.*: Class browser
	src/file_history.*: Browser-line history maintenance for files opened.
	src/help.*: Help system
	src/style-editor.*: Syntax highliting settings.
	src/start-with.c: Startup dialog.
	data/properties/*.properties: Language pack files for scintilla.

Shell/Plugin Segregation Rationale:
-----------------------------------
A consistent policy needs to be formulated and followed regarding what should
be part of the shell and what should be a plugin. The following points should
act as a rough guideline in this mater:
	o The shell without any plugins should be a usable editor which can
	manage a set of files and provide a reasonable set of helper functions
	on them. This includes file browsing, syntax highliting, search and
	replace, command execution, symbol browsing, etc.
	o The shell should consist of only those components for which no
	alternative implementation is planned. For example, CVS support
	should be a plugin since we plan to support multiple version control
	systems.
	o Any API which is deemed as generally useful to multiple components
	and is expected to be reasonablly stable over time should be part of
	the shell. An example of this is the launcher/tools support.
	o Any component which depends on teh availability of non-standard
	component which may not be useful to a major set of users should be
	a plugin. For example, valgrind support should be a plugin since
	many users may not have valgrind available and it works only under
	Linux.

Shell:
------
Following from the above, the first step towards code reorganization and
componentized development is defining functionality of the anjuta shell.
Ideally, the shell should consist of the folowing APIs:
	o Main window GUI
	o Enhanced plugins system
	o Miscellaneous utility functions
	o Editor and related lexers and functions
	o Project manager
	o Preferences, properties system and GUI customization dialogs.
	o Tools system
	o Docking system
	o Templating system
	o Common custom widgets
	o Source parser library

User Interface:
---------------
The current user interface is hardcoded and inflexible, mainly because of
the limitations of the used API. The GUI should be gradually converted to
use more flexible and advanced widgets:
	1. Edd Menu/Toolbar/Action for menu and toolbar items.
	2. GdlDock for all non-UI widgets.
	3. Libglade for all dialogs.

Plugin System:
--------------
The plugins system needs to be revamped as follows:
	o Register/unregister themselves
	o Load/unload themselves
	o Register/unregister multiple menu items/toolbars
	o Register/unregister multiple dock items.
	o Register/unregister their own preferences.
The shell should provide APIs for loading/unloading of plugins and a core
stable API for plugins to do the above. We should check out the anjuta2 code
to see if we can reuse the plugins system.

In order to keep the IDE lightweight and simple, we would like to avoid
Bonobo code as much as possible. To this end, the plugin system will be
implemented using plain GModule and shared libraries. In the future, we
might be adding support for Bonobo components but currently, the focus
is not on that.

Editor:
-------
We currently use scintilla for the editing component. Unfortunately, the
scintilla code is too tightly bound to the code code, which makes scintilla
upgrades extremely difficult and time consuming. We need to be able to segregate
scintilla into an external dependency.  For this, we need to:
	o Widgetify the editor code
	o Make it an external dependency so that scintilla can be upgraded
	  independently of anjuta.
	o Segregate the preferences system into it's own library.
	o Have a front-end to lexers properties files.
	o Better integration of lexers with sourcebase.
	o Use loadable lexers segregated from main scintilla codebase.
 
In order to segregate the editor code into it's own component, we should replace
scintilla/* and aneditor*.* with a GtkScintilla2 based widget. It might be a good
idea to simply use GtkScintilla2, improving it in the ways we require, and have
it as an external dependency. The text_editor*.* code should be simplified and
moved into an 'editor' subdirectory, under the shell directory. Since we do not
plan to support multiple editors, we can make the editor APIs part of the core
API and have a mandatory dependency on GtkScintilla2.

The scintilla editing component also needs some GTK2 specific improvements, esp.
related to the use of pango and input methods. We need to ensure that these
issues come to focus on the scintilla ML and adequate attention is given to
fixing these issues.

Preferences:
------------
The current preferences and properties system is IMO one of the most powerful
features of anjuta, and we need to keep it intact, and part of the core shell.
However, some things need to be done for this to happen effectively:
	1. Segregate from scintilla into it's own C library.
	2. Add support for callbacks for getting pref. values.
	3. Support multiple backends in the long term.

The preferences GUI is currently quite clean. We only need to ensure that it
supports integration with preferences of other plugins to have a sinple point
of customization.

Terminal:
---------
The terminal code is quite intermingled with the message-manager. The latter
should be replaced with GdlDock based widget for flexibility. The terminal should
become a plugin and be segregated into it's own directory. This can act as a
good test bed for the plugins system. Ideally, this is the first functionality
that we should attempt to move into the plugins architecture.

File Tree:
----------
The current file tree needs to be tuned and made into a core widget and part of
the shell, since it can be used in numerous ways. The CVS specific code should
be removed and dependency on tagmanager should be removed. The project manager
should use this widget but it should be usable outside the project manager as
a standalone widget as well. The file tree should be a singleton and have a
clean API for manipulation. The file tree preferences should be merged with the
main preferences dialog.

Debugger:
---------
After the terminal, the debugger is the key candidate for move to the new plugins
system. This is because it has a fairly complicated functionality, uses multiple
actions and dock windows, and might have different alternative implementations
not based on the current GDB backend. The project manager should control the
loading/unloading of the debugger. The UI (menu/toolbars) are mingled with the
other shell GUI code and need to be segregated into a set of dialogs (glade
file) and an Egg* UI file.

Parsers:
--------
Tagmanager dependency needs to be removed and replaced by sourcebase. Sourcebase
has much better parsers and will be more powerful in other aspects as well. It
is envisaged that sourcebase will be ready for inclusion by the time code cleanup
is done. Since sourcebase is pretty tightly linked with the project manager and
the editor, it needs to be made a core dependency rather than a plugin. The
class browser needs to be widgetified and changed to use sourcebase as the
backend. The autocomplete/calltip code also needs to be changed to use sourcebase
instead of tagmanager. Further, sourcebase preferences need to be integrated with
the preferences dialog.

Version Control:
---------------
All version control code needs to be removed from the core shell and implemented
as plugins, one for each backend. The aim is to support CVS as the primary
backend. Currently, the cvs code is present in more-or-less working state.
The CVS plugin should be written in a way to provide more flexibility than the
current implementation. Further, it should be able to act as a starting point
for implementation of other version control backends. the CVS plugin should
use a file tree derived widget for showing the CVS information in a customized
file tree.

Launcher and tools:
-------------------
The current tools system is quite powerful and provides a good way to interact
with external commands along with the launcher impleemntation. They should be
made part of the core API along with the following enhancements:
	1. Segregate the tool front end (editor) and the backend.
	2. Extend launcher to handle multiple simultaneous executtions.
	3. Remove ZVT dependency from launcher code.
	4. Provide a clean API for plugins to use the tools system to interact
	with external executables.
	5. Allow saving of tools at global/user/project level.

Search/Replace:
---------------
The current advanced search/replace functionality is powerful enough to replace
all the older find/replace stuff, so these should be removed. Search/Replace
is part of the core shell along with the editor. The following cleanups need to
be made:
	1. Segregate S/R backend from front-end.
	2. Allow interruption on execution of long search/replace activity.
	3. Have multiple front-ends whcih use the same backend, e.g.
		o Simple Search in current file.
		o I-Search
		o Search/replace in curent file.
		o Advanced search/replace
	4. Allow the user to save search/replace settings and give them names.

Build System:
-------------
Each build system should be a seperate plugin that interfaces with the core shell
API. The build system should not be part of the project manager. The project
manager should store information which plugin to load for the build system.
However, a reasonable amount of interaction is required between the project
manager and the build system, and this should be through a defined set of core
shell APIs. A build plugin should be capable of the following:
	o Load an existing build system using this backend.
	o Add/remove modify targets, sources and dependencies (+ atributes).
	o Tolerate limited amount of hand editing of the build files.
	o Use the PM API to register/unregister list of sources and targets.

The primary build backend is GNU autotools (autoconf/automake/libtool/make). We
need to write a standalone library for handling this backend and then create an
anjuta plugin using this library. It might be a good idea to have a look at
gnome-build and kdevelop autotools part for ideas/code.

UI Designer:
------------
With the stabilization of glade-3, we will have a set of widgets which can be
used by anjuta at compile time to have embedded Glade for building dialogs. We
should aim to provide a link with teh widget tree to automatically add stubs
and prototypes for all the callbacks defined by the user. Clicking on the
widget signal should take the user to the callback function. Since UI designer
is specific to GNOME projects, it should be implemented as a plugin. More
details need to be threshed out in order to make this work smoothly. In the
meantime (and after the integration), we should continue to provide the user
the choice to use his/her preferred UI designer through project preferences.

Templates:
----------
The current templates system consists of some project wizards, a class creator
plugin and some hardcoded menu entries to create boilerplate text. The system
is virtually impossible to reuse and will have to be thrown away. A new
templating system needs to be written and made part of the core API, which
should support the following:
	o Create new projects (replace current wizards stuff)
	o Create new target/source sets (e.g. a widget)
	o Create new source files (e.g. a header file)
	o Code snippets (e.g. GNU Licence block)

We can use empy or libtpt as the template language or write our own (not a good
idea IMO). Existing templates need to be converted to use the new system. A
template is a special kind of plugin which should use the core template API
to generate new projects/files/etc. We need to create a well thought-out design
for the templating system with ideas from anjuta2/kdevelop and implement it
from scratch.

Help System:
------------
Devhelp is, and should remain, the preferred method for diaplaying help. It
should be part of the core (shell) since integrated help is an essential part
of an IDE. Current integration with devhelp, however, is inadequete since
devhelp is accessed as an outside process. We should use the widgets provided
by devhelp to integrate more tightly with it as is done by VS and KDevelop. This
should not be very difficult to do.

Scripting:
----------
The core shell API should ideally be scriptable using multiple scripting
languages, so that users can write their own scripts to extend the functionality
of the IDE. The scripting interface should cover all aspects of the core API
including the shell, editor, plugins, tools, utilities, properties, templates,
etc. it should be possible to write plugins using bindings for the core API.

The primary scripting language we aim to support should be Python.

Plan:
-----
Here's what I propose we should do (in order) in order to achieve the above:
	o Copy the required widget code from libegg into the widgets directory.
	We will need the EggMenu, EggToolbar and EggCombo stuff. Also copy the
	other required widgets such as GdlDock from anjuta2 and the anjuta2
	plugins code. The plugin code will need some enhancements and
	modifications to use with the EggMenu/Toolbar code and to support the
	required features.
	o Convert the main GUI to use EggMenu and EggToolbar with UI files.
	Segregate the UI files of each component and use merging. Also, replace
	the use of GnomeDock widgets for teh left and bottom panes with GdlDock.
	o Create seperate directories for each planned plugin, for example,
	debugger, CVS, etc. Move the existing code to these directories along
	with the required files. Then convert to the plugin system.
	o Once the shell/plugin system is ensured to be working smoothly, we can
	undertake other cleanups like cleaning up the shell API, improving the
	project manager, moving to sourcebase, etc.
	o Remove all the scintilla code from the source tree and switch to
	GtkScintilla2 widget. This will be a big task and needs to land at one
	go to make sure that HEAD stays buildable. We will need to segregate
	the preferences files since they need to be in the API. We will also
	need to enhance the GtkScintilla2 widgwt to make sure we do not lose any
	functionality. We will also need to integrate the printing functionality
	using GnomePrint into the scintilla widget. This work can go on in
	paralle with the other activities.

Conclusion:
-----------
The full conversion into the proposed architecture would take a lot of time and
effort. The idea is to do it in a gradual manner while continuing with other
activities such as bug fixing, adding new features, etc. For this, we should
take the following approach:
	o HEAD should be buildable at all times.
	o The gnome-2-2 branch should be continued till HEAD is stabilized.
	o The 1.2.0 release should come from the gnome-2-2 branch.
	o Create subdirectoris under the main tree to work on cleanups, so that:
		o The code can be viewed by other people
		o They can be turned on easily when in buildable state.
		o The tree is always buildable.

For any questions regarding this document, please contact:
	o Biswapesh Chattopadhyay <biswapesh_chatterjee@tcscal.co.in>
	o Naba kumar <kh_naba@gmx.net>

