Hi Sebastien! Thanks for starting the discussion! > * Check usage of Anjuta in gnome-shell > Gnome shell is quite different from the old GNOME desktop so I think we > should at least check that Anjuta works find in this environment. I > imagine that we will have to improve some things, by example to open a > new window. I don't know if it's working using D-Bus message, just > command line options or something else. It's basically covered by the G(tk)Application class pretty well and there shouldn't be any need to use D-Bus directly. However, the main.c, anjuta.c and anjuta-app.c code is kind of ugly as it has gone through various transitions or the time being. Cleaning this up and fix some problems should really be done this cycle. > > * Improve Anjuta command line > Currently, we can open a file or a project from the command line. I > think it would be useful to be able to open a project wizard file and > perhaps allow to build a project. Such function could be perhaps > available from D-Bus interface too. See above, can be done using GtkApplication. Using .wiz files sounds useful. > * Review all bugs > We try to review bugs from time to time and I think we keep them under > control. But perhaps it would be interesting to explicitly review all of > them at the same time. There are some bugs that looks quite difficult to > fix or not really important for me, but I don't know if it's a general > feeling or not. We try to do that from time to time but it is of course always a partial review. Maybe we can find some day on a weekend where we do a mass review. > * Allow to load more autotools project > Currently, the parser doesn't support: > - conditional in Makefile.am or configure.ac > (https://bugzilla.gnome.org/show_bug.cgi?id=646532) > - configuration files added in macros > (https://bugzilla.gnome.org/show_bug.cgi?id=642785) > - concatenate operator (https://bugzilla.gnome.org/show_bug.cgi?id=650743). > Fixing these will allow to load more projects. > * Add more project backend > It can be useful to add a backend for CMake by example. > > > * Support more options in autotools project > At the moment quite a lot of options can be changed in the project > wizard only, like C++ support, internationalization, library support. I > think it would be better to allow to set this in the project manager. I > don't know which options are the most useful. > > > * Support quoting in Makefile.am and configure.ac > Currently, the parser recognize quotes but quotes are not added when new > data are written (https://bugzilla.gnome.org/show_bug.cgi?id=644534). > It's probably an useful function even if it's not obvious to implement. > Supported even more automake features and making them available to the user would be really great. I think we have come a long way with autotools support but we might be even better. > * Add missing source files on commit > I think the version control plugin (mainly git) should propose to add > all sources files when you commit some changes. Including project files > like new Makefile.am, when they are not already added. This is something the project-manager should tell the version control plugin when it adds files (or directories) and I think we should do that automatically (the user will see the summary of the files when he commits something anyway). > * Take care of indentation in project and file wizard generated files > I think we have to use the user defined indentation when generating > files from template. I think we can do it by having properties defining > how many space or tabs are used. Then it needs some scheme code and a > rewrite of all templates to use this new functions. It shouldn't be very > hard. This is reported quite often so it seems to be something that annoys people. I was thinking about something like a [+TAB+] tag in the template files but maybe there are better (and easier to maintain) options for it. This is quite high on the list of things to fix for me. > * Remember layout in GDL > I think it's the most annoying issue with GDL > (https://bugzilla.gnome.org/show_bug.cgi?id=569160) but it's not really > a bug more an improvement. It's not easy to do because I think we need > to have a function saving the position of the window before closing it > and be able to reopen the window at almost the same place if it is > reopen later with potentially other windows. That would be great but it seems difficult to do as you need deep knowledge on how gdl and gtk+ work. > * Support call graph > I would like to know how many time each function is used and in which > functions. It would be useful when reorganizing the code, in order to > easily find dead or seldom used parts. I don't know if we have to do > this in the symbol-db plugin or write a new one. See clang below. > * Move the template engine in a separate plugin > The template engine using autogen in the project wizard is used at least > by the file wizard too. It would be better to move the code in a > separate plugin. Probably just create a good common class in libanjuta to handle these things. > * Allow to rename variables and functions > It's an useful feature when re-factoring code. I don't know if it could > be part of the symbol-db plugin, the search plugin or another one. > In the big picture I see this as things that could be done with clang libraries at least for C/C++. Having a full parser for the code should simplify this but I don't know how to handle all the details, yet. > * Generate distribution package > This has been already proposed, I don't know how difficult is it. Will > it be possible to generate both .rpm and .deb? Could it be done without > being distribution specific? We could try to support it for the common projects we generate. At least rpm supports to depend on pkg-config information which we can provide but I am not sure about deb packages. In practice it is also quite hard to generate packages for distros you are not currently on if you don't use build services like OpenSuSE build service. > * Improve documentation > The documentation still need more works. Some plugins have almost no > documentation but I don't know which part is the most needed. This is one of those never-ending stories but we are getting better with every release so I hope we can at least cover all the core plugins for the next release. > * Make Anjuta starts faster > Anjuta is a bit slow to start. I need to experiment with GResources a bit which might allow us to do more efficient IO by compressing resources and loading them as a big chunk (at least big chunk per plugin). There might be other things we might be able to optimize. Regards, Johannes
Attachment:
signature.asc
Description: This is a digitally signed message part