Hi Sébastien! Am Samstag, den 02.04.2011, 11:52 +0200 schrieb Sébastien Granjoux:
I think it's better to not commit these changes in the master branch now to avoid disturbing translators. Then, perhaps we can create a new branch gnome-3-0 or gnome-3-2 and commit here else I will just wait a few days. It's really a first draft, it needs more work.
Yes, that's true.
I have tried to organize the page by plugin. Mallard is quite useful for this. I think it would be probably useful to have a page listing all plugins as the user could have to enable some of them.
I am not sure if this is an entirely useful approach. The idea of task-based help is to address the problems a user might see independently from the technical background. In many cases there might be multiple plugins necessary for a task and the user doesn't have to be aware of all the plugins that are activated automatically.
I have described for the project manager several points which are really specific to the autotools plugin. The issue is that it's the only backend allowing to write the project files.
I think it is ok to be specific to the autotools plugin as we have no other real backend anyway and most people (especially those not so familiar with the build infrastructure) will use it.
I have found an issue with the project manager too. If you set C flags on a target, autotools creates a specific target named "target_name-source_name.o" and the compile command is not working anymore as it tries to make "source_name.o". I think only the project manager can take care of this and define the right object target. But it will change the project tree (we can keep the tree view though) as currently the parent of a source file is the final program, not an object file.
That should be fixed and I don't see a real problem with a change in the project tree.
Another issue is that all explanations about module and package are quite specific to C program. I don't know if it applies to Vala or Java libraries. I imagine that it's a bit different and I don't know how to present that. Putting all informations on one page will make it quite long. But having an additional index page and then the right information seems a bit annoying. A nice solution could be to have a context, allowing to display Anjuta documentation in C context or Java context.
I think it is about the same for Vala and Java. If we (or someone else) finds a difference later, we can still add a note at those paragraphs. As we have no real way to detect the project language it is rather difficult to display context sensitive help.
I have described several topics more related to autotools than Anjuta and I think I need to add more details but it will make the documentation even bigger. Do you think we should continue in this direction or concentrate on Anjuta only giving http links to autotools manual?
There is an autotools manual already (so it's pretty bad...) and I don't think our job is to duplicate it. But we might still want to explain some (common) corner cases.
Do you think, it's useful to add more advanced information in this manual. By example the description of the project wizard template format?
These things should be in the reference manual. We can also have this is mallard if we want but I don't think it should be part of the user manual.
I think rewriting the documentation would be really useful but needs a lots of time. Perhaps we can fix it as a goal for the next release.
Definitely! Thanks, Johannes
Attachment:
signature.asc
Description: This is a digitally signed message part