Anjuta Roadmap
3.4
This are features somebody is working on and that are likely finished by the time 3.4 is released.
Searching
Find in Files / Refactoring (Johannes Schmid)
Project Manager
- Improve project manager dialog (Done)
- Read included files in Makefile.am and configure.ac (Done)
- Support configure variable in Makefile.am (Done)
Auto-tools project back-end
Support module in (library loaded dynamically) (Sébastien Granjoux)
Support non recursive make (Sebastien Granjoux)
Debug Manager
- Merge thread and stack trace window (Done)
Scintilla editor
- Improve style editor dialog (Done)
Future
Language support
- Add member completion based on symbol-db plugin
- Integrate devhelp into calltips
Build
Adapt build system to various environment Anjuta/Roadmap/BuildSystemCleanUp
Symbol-DB
- Provide "Locals" support for files not contained in the project on-the-fly (maybe in-memory database).
Project wizard template
- It can be nice to accept a .wiz file as an argument of anjuta and automatically create a new project in this case. This will allow someone to distribute himself a template that can be easily used to create a new project.
Project manager
- Allow more drag and drop operation in the project manager view
Packaging and Deployment
- It would be great to have some kind of "deploy"-mechanism for automatically building debian and rpm packages. I know that this is very tricky but it would be nice to have anyway.
- This issues comes up again at the Developer Documentation/Tools hackfest. Packaging can be difficult, choosing which distributions to target is confusing for new developers, and there is no support from IDE here. Other platforms do a much better job at it than we do (think Android, iOS). A few already existing project could be used here
General aspects
- Faster startup time. Anjuta is a bit slow to be used just for editing one file. It will be useful to see if this can be improve. The application needs to be profiled to study where performance bottlenecks are.
- Global rename, code refactoring. From time to time, we change the name of one type or one variable, it would be really useful if we can easily do this. Currently, we can use the search plugin, but if the variable has short name, it will probably give too much false positives. We can probably do much better parsing the source code, perhaps using information from symbol-db.
Editor (depends on GtkSourceView)
- code-folding
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.
Anjuta Online ideas
- Online sharing and fetching of symbol-db files for various libraries. Currently, they are all generated for everyone at the time a project is opened for the first time. It's a lot of wasted CPU cycles. Instead, we could let users upload the generated files and have them downloaded by those who needs. Clearly, the db file needs to be indexed with library name, version and anjuta compatibility number.
Bugzilla integration: This is clearly the biggest service used when developing software. Last time we thought about doing something with it, it was deemed not ready because bugzilla did not provide any API interface. Things might have changed now, but I don't know for sure. At least there are ways to submit patches from git to bugzilla, so I would assume something is happening. This would also include patch management from bugzilla. Maybe this will help: https://fedorahosted.org/python-bugzilla/ and https://wiki.mozilla.org/Bugzilla:Addons.
- Online knowledge base: This is something I believe would be cool. The idea is that users would have a plugin running in Anjuta where he could get/contribute small tips about the things he is doing or new discoveries related to his project. The submitted tips will be of course be contextually associated with the kind of project he has open, such as libraries it's using, the project he working one, etc. He could also search for tips from other users when he needs some. Or have automatic tip per session shown. It can also serve as online-faq. And perhaps even provide a way to vote its userfulness for others to get more relevance.
- Instant messaging integration: Now, I am not talking about your average chat thing which you get from desktop anyways. But rather a tighter integration related to the current project open. IRC channels are great example, but they are not automatic and developers have to handle them separately. What if it's there automatically when he opens the project, in a plugin? This will give him constant "support" channel automatically. We can think about Empathy integration. It supports irc, xmpp and other protocols, so the project can decide which one to use. Empathy has a widgetized ways to embed in applications, so coming up with a plugin to embed it in Anjuta and auto join a channel/conference-room would be just cool. Oh, you get video calls as bonus also :).
- One click "start hacking" feature: The projects websites provide a link to a simple file, presumably with "Develop with Anjuta" logo. Which the entrapped developer clicks, Anjuta handles the mime, opens with the import project plugin, installs the missing dependencies (packagekit integration), prepares the build.... The file of course details where the repository is, what the needed dependencies are, and so on. I think DOAP [1] format is a nice way to make it available. Another alternative is to use project's .anjuta file.
- We can have an list of project fetchable and searchable by a plugin in Anjuta from anjuta website for the user to just select and start. This would require a form in anjuta website for people to register existing project details and some kind of db to hold the data. It does not have to be a complex service (no account needed or anything like that, as long as we make sure bots can't do it). This is actually opposite of (7), where the user starts from Anjuta, rather than from project's website.
More ideas
- Fast keyboard operation for Anjuta. I tried using Anjuta just with keyboard without mouse. It wasn't easy and in some case quite impossible. While most menu items have keyboard shortcuts, there are many more things that are only doable by mouse, or takes just unimpressive amount to effort to navigate using ctrl-tab across our docking space. We can try to invent emacs/vim style command plugin which will make everything accessible with short commands, and of course some ways to register new commands by plugins.
Online repository of project templates. Which anjuta can get when the user does New->Project and list them.
- What about having online also some magic code to add libraries/checks/automake snippets to configure.ac? I always panic when I have to add code to configure.in and similar... and I think a new linux user will complain too.. Probably, in general a code snippet library.