Introduction: ------------- This document is the roadmap for future development of anjuta. The goal of Anjuta DevStudio is to provide a truely customizable and extensible IDE framework and at the same time provide the basic implementations of common development tools. libanjuta is the framework that realizes the Anjuta IDE plugin framework and Anjuta DevStudio realizes many of the common development plugins. Anjuta 2.x (trunk): ------------------- Anjuta 2.x development series has new extensible plugin architecture and all the plugins have been ported to this new plateform. The libanjuta interface defines all the IDE APIs and is used to write anjuta plugins. In addition, it also provides many utility classes. Following are the major milestones that we will attempt to reach by the estimated dates given. There will be smaller releases in-between, mainly stablization and bugfix releases. Milestone 2.2.0 - (Estimated release time Apr 2007): - Complete libanjuta API definition and documentation - Partial user documentation - Fix GDL to restore widgets dock locations correctly. - Complete glade plugin integration - Bug fixing and stable release. Optional other stuff - ants project management backend for gnome-build - ants build system plugin. - online anjuta plugin installer - Better support for other languages (Java, Python, Ruby, C#) - More plugins. Projects: --------- Given below are some major tasks that no one has yet considered doing. If you are interested in having these done, you will get our blessings :-). You will also get our full support while taking up these projects. Please subscribe to our development mailing list if you want to discuss these further. Some helpful links that will give initial guide are: - HACKING: http://anjuta.org/hacking - API docs: http://anjuta.org/documents/libanjuta/ gtranslator plugin for Anjuta: ------------------------------ gtranslator is a software used by translators to edit and update .po files, which are localization files in a project. This plugin will be responsible for integrating gTranslator in Anjuta DevStudio. The implementation will closely follow the way we have integrated DevHelp in Anjuta. The first task involves collaborating with gtranslator developers to have gTranslator in form of a library that will provide all the neccessary widgets to be embeded in Anjuta. The approach would be to segregate all UI (menus and toolbars) controls from the main engine. The main engine (library) should contain only the main widgets and API for their interaction with the UI and themsleves. gTranslator executable will itself use this library and implement the UIs within. Once that has been done and neccessary library interface has been created in gTranslator, we can move ahead with creating the actual Anjuta plugin. If gTranslator library creation is done properly, the Anjuta plugin should not involve much work, because the only thing that matters at this point is to wrap the library with our own UI and embed the widgets in Anjuta Shell. Much of this can be easily understood from existing plugins (e.g. devhelp plugin). Links: - gtranslator: http://gtranslator.sourceforge.net/ conglomerate integration ------------------------ conglomerate is a nice application for editing xml files, such as docbook articles and book. In anjuta, it will be particularly helpful to write software documentations. Integrating it will pretty much follow the same approach as with devhelp and gtranslator. Links: -http://www.conglomerate.org/ Users manual, tutorials and FAQ update: --------------------------------------- This is a non-technical work, but is an extremely important part of Anjuta project. We used to have a very handy users documentation in Anjuta 1.x series, but they are no longer useful for Anjuta 2.x series. The task envolve getting familiar with Anjuta 2.x operation and updating the existing documents. The documents are written in docbook sgml format. So, in addition to being able to write good english and having some basic programming/development skills, one must also be familiar with writing sgml documents. Screenshots should be taken with default GNOME theme with shadow drops. Uneccessary screenshots that could be effectively explained in text should be avoided as much as possible. For compiling FAQ (frequently asked questions), one needs to research Anjuta mailing lists, bugzilla discussions and forums to identify repeated questions and answers that would qualify for FAQ. Glade3 Integration: ------------------- We already have glade3 integration in anjuta working. The improvements involve interfacing it with anjuta glade plugin for signals navigation, stubs creations and project files negotiations. Signals navigation" means when user selects a signal in glade properties editor, Anjuta automatically brings up the implementation of that signal in its editor. This can be accomplished with SymbolBrowser plugin in anjuta, that keeps tab on all symbol updates in the project. Using the signal handler signature, Anjuta glade plugin can take help of symbol-browser plugin to find the location of function definitions in the project. "Stubs creation" means when the user adds new signals, Anjuta glade plugin automatically creates the stub for the signal handler using gtk signal introspection. The signal prototype can be identified with the introspection. Where and how the stubs are added in project is a matter of dissussion. "Project files negotiation" means when user adds file via glade (e.g. images in dialogs), glade will notify anjuta to add the file in project and give a change to relocate it within the project. Anjuta needs to handle this request and add the files in project (possibly prompting user for relocation). Anjuta also needs to make sure glade is able to find them later. Links: - Glade3: http://glade.gnome.org/todo.html Implement preferences as interface: ----------------------------------- Currently all plugins register their preferences at activate time. This has the obvious performance issue of unneccessarily overloading plugin activation It can stack up significantly when lots of plugins are activated simultaneously. We want to get rid of this and only construct the preferences pages at request time. Define a IAnjutaPreferences interface with construct() method (in addition to other related methods) in it. Then implement this interface in all plugins having preferences. Initialize the plugin preferences in construct method, instead of what currently is been done in activate_plugin(). Then when user activates Settings->Preferences, find all "loaded" plugins that implement IAnjutaPreferences and call construct() on them. Display the newly constructed preferences dialog. Destroy the preferences dialog when it is closed.
