Hi!
I have looked at other documentation, empathy one by example, it really tell you which button should be used. It's possible that someone doesn't find the context menu himself.
OK, in general the empathy documentation is probably the most researched one from the docs-teams so I guess it's fine.
What do you call custom environment variable? It has been requested but it's not possible to set them for build tools except by writing a plugin.
Well, you can set things like 'CFLAGS=-bla' in the text entry in the configure dialog, can't you?
3. I put the description of each dialog on one page and I have created a index for them. Do you think it's useful?Hmm, in general the documentation team wants to go away from explaining stuff in the sense of dialogs. So I think it would be better to have points like "What can I do if anjuta doesn't recognize the compiler messages" instead of "Configure the build plugin -> Disable translations". At least this is how I understand that modern help should work.I have looked at empathy documentation, and if you look for details you arrive to a page which explain each setting like: account-irc.page or account-jabber.page. It doesn't explicitly described a dialog but it's quite close. I'm not sure that "What can I do if anjuta doesn't recognize the compiler messages" is really better because you can add "What can I do if I cannot find more information about a message on internet" and perhaps other uses that I have missed. Then, adding "What can I do if anjuta doesn't recognize the compiler messages" could be useful in a FAQ but I think a description of each setting is useful. Then, if you think it's not needed we can remove the index of all dialogs.
If the docs team does this I guess it's fine. Actually I like the idea of having "Help" buttons in those dialogs as it would be natural for a user unsure what he needs to select. I just thought the docs team would have a different idea now but it seems wron.
4. I think, we could have one page for each plugin too. I have done it but I haven't added an index for all plugins yet.This is only useful for the non-essential plugins as the user wouldn't recognize the others as plugins anyway, they should feel part of the core program.Ok, I will let it like this.
I think it's fine for the non-essential plugins that are not activated automatically or by default.
It would be nice to have a complete Mallard documentation for the next stable release. Is there some volunteers?I hope I can find some time to add these topics but not sure how far I will get.I hope you won't be the only one to help on that. Should we switch to the Mallard documentation anyway for the next release or stay on the current one if there is no improvement?
I think we should definitly switch to the new mallard documentation. I will change that in git with the 3.1.3 release today. Currently the docs are incomplete but they will fill with time and translators will be able to translate what we already have. Thanks and regards, Johannes
Attachment:
signature.asc
Description: This is a digitally signed message part