Anjuta Roadmap

Now that Anjuta 2.4.0 is more or less getting into shape and our initial goals pretty much fulfilled, we can already look into what we should focus on next couple of major releases. This is a playground for ideas for features for future Anjuta versions.

Pending tasks for 2.6

Clearly, before we even think of adding anything new, we need to complete existing tasks.

General

• Use new platform features and get rid of deprecated dependencies by porting to Gio/GVfs, GRegex, GtkAssistent (instead of GnomeDruid), GtkRecent (instead of EggRecent) etc.

Document Manager

• multiple document views (patches in bugzilla; needs proper review)

Scintilla

• Remove scintilla editor (?)

GtkSourceView

• integrate GtkSourceCompletion

• use gio (hopefully integrated into gtksourceview library)
• code-folding
• inspection of text type

Symbols

• New symbol-db plugin (and thus remove symbol-browser)
• Support more languages (python, etc.)

Searching

• Merge new search plugin
• Fix utf-8 issues
• Possibly use GRegex instead of pcre

Language support

• Write language support plugins for more languages
• Add member completion based on symbol-db plugin
• Integrate devhelp into calltips

Version Control

• Fix-up IAnjutaVCS interface
• Add/Remove/Rename of files in file-manager and/or project-manager should update the status of VCS
• Show file status in file-manager (Added/Removed/Modified/Conflicted)

• git plugin

• darcs plugin

Glade

• Completing glade integration

• GtkBuilder

Build

• Add ability to build single files (without Makefile)
• Add make options (-k -j etc.)

• Anjuta/Roadmap/BuildSystemCleanUp

Debugger

• Improve debugger run dialog (bug #513545)
• Support remote debugging (bug #503764)
• Check if the program is up to date before starting debugger (bug #378903)

Goals for 2.6+

User Friendliness

Make Anjuta extremely "ready" and laziness friendly. This is really a very important aspect of Anjuta. Most expert programmers likely to be able to figure out intricacies of build systems are already happy with emacs/vim. What left are those people who don't want to be bothered with such science and just wants to get started on his work.

Considering such demographics of Anjuta users, it is clearly in our goals to make them happy by providing necessary 'clerical' supports to make his life easier. It also allows him to spent his time on more important tasks, such as the actual coding.

Here are some ideas that would follow this goal:

• To be able to automatically bring in all the necessary development dependencies for the project he is starting. This will involve fetching and installing any missing packages in his system when he creates a new project from the wizard. Right now, there is a serious amount of complaints going on because he couldn't compile his first Anjuta project (e.g. missing gcc or make).
• Some sort of abstraction has to be invented to accommodate differences in platform specific packaging systems. I already did some research on similar cases in other projects, such as automatic installation of media codecs in Ubuntu when you try to play an unknown media, but it was more like a hack adapted for ubuntu (there is a python script that does it). We will need something more generic and versatile.

[ You guys might want to seriously consider using libpackagekit. Refer http://packagekit.org - RahulSundaram]

• Some plugins will fail to work if their corresponding backend programs are not installed (e.g. cvs, valgrind, indent, ctags etc.). The trouble is that such run-time program dependencies are not allowed in package dependencies. Besides, we shouldn't necessarily assume that the user is interested in all the plugins shipped with anjuta. So fulfilling those run-time dependencies when the user first activates the plugin would benefit.
• We can have a similar "install missing programs" using the same approach mentioned before.
• Ramping up packages management for projects. Currently, we have a really basic packages (dependencies) management which isn't easy to use. A sort of wizard to help the user add or remove depending packages and taking care of updating affected targets automatically will make developers life much easier.

Extensibility

To provide means to extent Anjuta in varying ways.

• Encouraging bindings for other languages. This is essentially a gateway to many interesting plugin developments involving language specific plugins. I believe our framework is at very good position to support language bindings, thanks to Sebastien. But we need more efforts to promote this and give guidance (documentation, website, demonstration, examples) to prospective 3rd party developments.
• Provide remote templates download for user to just browse and find his right template. Also to allow uploading new templates. This will need some kind of web service, but I think it can be worked out somewhere in anjuta.org. However, the biggest issue is maintaining it in user's installation. Maybe it's just better to depend on host packaging system to avoid reinventing the wheel?

Automated regression and module testing

• Since we are now part of GNOME suit, reliability is becoming more important. We need to focus on automated testing also. While clearly we don't have the resource to go full blown test suit, we can hopefully have some regression testing for complicated features that have way too many test cases typically not easily covered in normal usage.
• Module testing is also interesting. We could come up with some generic module testing setup that would allow independent plugin testing without involving other plugins too much. We have some basic setup using anjuta-shell, but something better can be thought out.