ROADMAP

   1 Introduction:
   2 -------------
   3 This document is the roadmap for future development of anjuta.
   4
   5 The goal of Anjuta DevStudio is to provide a truely customizable and
   6 extensible IDE framework and at the same time provide the basic implementations
   7 of common development tools. libanjuta is the framework that realizes the
   8 Anjuta IDE plugin framework and Anjuta DevStudio realizes many of the common
   9 development plugins.
  10
  11 Anjuta branches:
  12 ----------------
  13 Anjuta currently has two main branches, ANJUTA_1_2_0 and HEAD. The ANJUTA_1_2_0
  14 branch is stable branch and corresponds to anjuta-1.x release series. The
  15 HEAD branch is the anjuta-2.x releases and is the latest development series.
  16
  17 Anjuta 2.x development series has new extensible plugin architecture and all
  18 the plugins have been ported to this new plateform. The libanjuta interface
  19 defines all the IDE APIs and is used to write anjuta plugins. In addition, it
  20 also provides many utility classes.
  21
  22 Following are the major milestones that we will attempt to reach by the
  23 estimated dates given. There will be smaller releases in-between, mainly
  24 stablization and bugfix releases.
  25
  26 Milestone 2.0.2 - (Estimated release time April 2006)
  27 - Compelete autotools project management implementation (gnome-build)
  28 - Complete libanjuta API definition and documentation
  29 - Partial user documentation
  30
  31 Milestone 2.1.0 - (Estimated release time Oct 2006):
  32 - Complete Users manual, tutorials and FAQ
  33 - Include new debugger from anjuta-new-debugger branch
  34 - Fix GDL to restore widgets dock locations correctly.
  35 - Fix GDL to restore widgets geometry correctly on dock.
  36 - Complete glade plugin integration
  37 - Complete API implementations in plugins (i.e no missing implementation stubs).
  38
  39
  40 Milestone 2.2.0 - (Estimated release time Jan 2007):
  41 - Bug fixing and stable release.
  42
  43 Optional other stuff
  44 - ants project management backend for gnome-build
  45 - ants build system plugin.
  46 - online anjuta plugin installer
  47 - Better support for other languages (Java, Python, Ruby, C#)
  48 - More plugins.
  49
  50 Projects:
  51 ---------
  52 Given below are some major tasks that no one has yet considered doing. If you
  53 are interested in having these done, you will get our blessings :-). You will
  54 also get our full support while taking up these projects. Please subscribe
  55 to our development mailing list if you want to discuss these further.
  56
  57 Some helpful links that will give initial guide are:
  58 - HACKING: http://anjuta.org/hacking
  59 - API docs: http://anjuta.org/documents/libanjuta/
  60
  61 gtranslator plugin for Anjuta:
  62 ------------------------------
  63 gtranslator is a software used by translators to edit and update .po files,
  64 which are localization files in a project. This plugin will be responsible
  65 for integrating gTranslator in Anjuta DevStudio. The implementation will
  66 closely follow the way we have integrated DevHelp in Anjuta.
  67
  68 The first task involves collaborating with gtranslator developers to have
  69 gTranslator in form of a library that will provide all the neccessary widgets
  70 to be embeded in Anjuta. The approach would be to segregate all UI (menus and
  71 toolbars) controls from the main engine. The main engine (library) should
  72 contain only the main widgets and API for their interaction with the UI and
  73 themsleves. gTranslator executable will itself use this library and implement
  74 the UIs within.
  75
  76 Once that has been done and neccessary library interface has been created
  77 in gTranslator, we can move ahead with creating the actual Anjuta plugin. If
  78 gTranslator library creation is done properly, the Anjuta plugin should
  79 not involve much work, because the only thing that matters at this point is
  80 to wrap the library with our own UI and embed the widgets in Anjuta Shell.
  81 Much of this can be easily understood from existing plugins (e.g. devhelp
  82 plugin).
  83
  84 Links:
  85 - gtranslator: http://gtranslator.sourceforge.net/
  86
  87 Performance Profiler plugin:
  88 ----------------------------
  89 gprof is a command line tool for profiling program performance. The executable
  90 is required to be compiled with -p flag and when the program is executed,
  91 a profiling info is collected in a file. After the execution is done, gprof
  92 can be used to interpret the profile data. This plugin parses the output from
  93 gprof and presents the information in different views -- text, lists
  94 and graphs. It is similar to the valgrind plugin given below.
  95
  96 Users manual, tutorials and FAQ update:
  97 ---------------------------------------
  98 This is a non-technical work, but is an extremely important part of Anjuta
  99 project. We used to have a very handy users documentation in
 100 Anjuta 1.x series, but they are no longer useful for Anjuta 2.x series.
 101 The task envolve getting familiar with Anjuta 2.x operation and updating the
 102 existing documents. The documents are written in docbook sgml format. So,
 103 in addition to being able to write good english and having some basic
 104 programming/development skills, one must also be familiar with writing sgml
 105 documents. Screenshots should be taken with default GNOME theme with shadow
 106 drops. Uneccessary screenshots that could be effectively explained in text
 107 should be avoided as much as possible.
 108
 109 For compiling FAQ (frequently asked questions), one needs to research Anjuta
 110 mailing lists, bugzilla discussions and forums to identify repeated questions
 111 and answers that would qualify for FAQ.
 112
 113 Glade3 Integration:
 114 -------------------
 115 We already have glade3 integration in anjuta working. But the implementation
 116 is incomplete and not fully usable. The main reason is that glade3 is not
 117 fully ready for general consumption. One part of this task involve
 118 collaborating with glade3 developers and helping them complete it so that it
 119 is fully compatible with glade2 files and libglade.
 120
 121 The second part involves interfacing it with anjuta glade plugin for
 122 signals navigation, stubs creations and project files negotiations.
 123
 124 Signals navigation" means when user selects a signal in glade properties editor,
 125 Anjuta automatically brings up the implementation of that signal in its editor.
 126 This can be accomplished with SymbolBrowser plugin in anjuta, that keeps tab
 127 on all symbol updates in the project. Using the signal handler signature,
 128 Anjuta glade plugin can take help of symbol-browser plugin to find the location
 129 of function definitions in the project.
 130
 131 "Stubs creation" means when the user adds new signals, Anjuta glade plugin
 132 automatically creates the stub for the signal handler using gtk signal
 133 introspection. The signal prototype can be identified with the introspection.
 134 Where and how the stubs are added in project is a matter of dissussion.
 135
 136 "Project files negotiation" means when user adds file via glade (e.g. images
 137 in dialogs), glade will notify anjuta to add the file in project and give
 138 a change to relocate it within the project. Anjuta needs to handle this
 139 request and add the files in project (possibly prompting user for relocation).
 140 Anjuta also needs to make sure glade is able to find them later.
 141
 142 Links:
 143 - Glade3: http://glade.gnome.org/todo.html
 144
 145 Implement preferences as interface:
 146 -----------------------------------
 147 Currently all plugins register their preferences at activate time. This has
 148 the obvious performance issue of unneccessarily overloading plugin activation
 149 It can stack up significantly when lots of plugins are activated simultaneously.
 150 We want to get rid of this and only construct the preferences pages at
 151 request time.
 152
 153 Define a IAnjutaPreferences interface with construct() method (in addition
 154 to other related methods) in it. Then implement this interface in all plugins
 155 having preferences. Initialize the plugin preferences in construct method,
 156 instead of what currently is been done in activate_plugin(). Then when user
 157 activates Settings->Preferences, find all "loaded" plugins that implement
 158 IAnjutaPreferences and call construct() on them. Display the newly constructed
 159 preferences dialog. Destroy the preferences dialog when it is closed.