3 This document is the roadmap for future development of anjuta.
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
13 Anjuta 2.x development series has new extensible plugin architecture and all
14 the plugins have been ported to this new plateform. The libanjuta interface
15 defines all the IDE APIs and is used to write anjuta plugins. In addition, it
16 also provides many utility classes.
18 Following are the major milestones that we will attempt to reach by the
19 estimated dates given. There will be smaller releases in-between, mainly
20 stablization and bugfix releases.
22 Milestone 2.2.0 - (Estimated release time Apr 2007):
23 - Complete libanjuta API definition and documentation
24 - Partial user documentation
25 - Fix GDL to restore widgets dock locations correctly.
26 - Complete glade plugin integration
27 - Bug fixing and stable release.
30 - ants project management backend for gnome-build
31 - ants build system plugin.
32 - online anjuta plugin installer
33 - Better support for other languages (Java, Python, Ruby, C#)
38 Given below are some major tasks that no one has yet considered doing. If you
39 are interested in having these done, you will get our blessings :-). You will
40 also get our full support while taking up these projects. Please subscribe
41 to our development mailing list if you want to discuss these further.
43 Some helpful links that will give initial guide are:
44 - HACKING: http://anjuta.org/hacking
45 - API docs: http://anjuta.org/documents/libanjuta/
47 gtranslator plugin for Anjuta:
48 ------------------------------
49 gtranslator is a software used by translators to edit and update .po files,
50 which are localization files in a project. This plugin will be responsible
51 for integrating gTranslator in Anjuta DevStudio. The implementation will
52 closely follow the way we have integrated DevHelp in Anjuta.
54 The first task involves collaborating with gtranslator developers to have
55 gTranslator in form of a library that will provide all the neccessary widgets
56 to be embeded in Anjuta. The approach would be to segregate all UI (menus and
57 toolbars) controls from the main engine. The main engine (library) should
58 contain only the main widgets and API for their interaction with the UI and
59 themsleves. gTranslator executable will itself use this library and implement
62 Once that has been done and neccessary library interface has been created
63 in gTranslator, we can move ahead with creating the actual Anjuta plugin. If
64 gTranslator library creation is done properly, the Anjuta plugin should
65 not involve much work, because the only thing that matters at this point is
66 to wrap the library with our own UI and embed the widgets in Anjuta Shell.
67 Much of this can be easily understood from existing plugins (e.g. devhelp
71 - gtranslator: http://gtranslator.sourceforge.net/
73 conglomerate integration
74 ------------------------
75 conglomerate is a nice application for editing xml files, such as docbook
76 articles and book. In anjuta, it will be particularly helpful to write
77 software documentations. Integrating it will pretty much follow the same
78 approach as with devhelp and gtranslator.
81 -http://www.conglomerate.org/
83 Users manual, tutorials and FAQ update:
84 ---------------------------------------
85 This is a non-technical work, but is an extremely important part of Anjuta
86 project. We used to have a very handy users documentation in
87 Anjuta 1.x series, but they are no longer useful for Anjuta 2.x series.
88 The task envolve getting familiar with Anjuta 2.x operation and updating the
89 existing documents. The documents are written in docbook sgml format. So,
90 in addition to being able to write good english and having some basic
91 programming/development skills, one must also be familiar with writing sgml
92 documents. Screenshots should be taken with default GNOME theme with shadow
93 drops. Uneccessary screenshots that could be effectively explained in text
94 should be avoided as much as possible.
96 For compiling FAQ (frequently asked questions), one needs to research Anjuta
97 mailing lists, bugzilla discussions and forums to identify repeated questions
98 and answers that would qualify for FAQ.
102 We already have glade3 integration in anjuta working.
103 The improvements involve interfacing it with anjuta glade plugin for
104 signals navigation, stubs creations and project files negotiations.
106 Signals navigation" means when user selects a signal in glade properties editor,
107 Anjuta automatically brings up the implementation of that signal in its editor.
108 This can be accomplished with SymbolBrowser plugin in anjuta, that keeps tab
109 on all symbol updates in the project. Using the signal handler signature,
110 Anjuta glade plugin can take help of symbol-browser plugin to find the location
111 of function definitions in the project.
113 "Stubs creation" means when the user adds new signals, Anjuta glade plugin
114 automatically creates the stub for the signal handler using gtk signal
115 introspection. The signal prototype can be identified with the introspection.
116 Where and how the stubs are added in project is a matter of dissussion.
118 "Project files negotiation" means when user adds file via glade (e.g. images
119 in dialogs), glade will notify anjuta to add the file in project and give
120 a change to relocate it within the project. Anjuta needs to handle this
121 request and add the files in project (possibly prompting user for relocation).
122 Anjuta also needs to make sure glade is able to find them later.
125 - Glade3: http://glade.gnome.org/todo.html
127 Implement preferences as interface:
128 -----------------------------------
129 Currently all plugins register their preferences at activate time. This has
130 the obvious performance issue of unneccessarily overloading plugin activation
131 It can stack up significantly when lots of plugins are activated simultaneously.
132 We want to get rid of this and only construct the preferences pages at
135 Define a IAnjutaPreferences interface with construct() method (in addition
136 to other related methods) in it. Then implement this interface in all plugins
137 having preferences. Initialize the plugin preferences in construct method,
138 instead of what currently is been done in activate_plugin(). Then when user
139 activates Settings->Preferences, find all "loaded" plugins that implement
140 IAnjutaPreferences and call construct() on them. Display the newly constructed
141 preferences dialog. Destroy the preferences dialog when it is closed.