Hi Morten,
Hence I have some suggestions to make:
1.) It was hard to me to find out how I actually use this. Until I found the toolbar which gives access to the functions. An extra "doxygen" menu would be fine.
This is now done.
2.) In addition some of the options should go into the editors context menu, too (like "add doxygen comment at current editor position) for convenience.
As is this.
3.) The "DOT_PATH" is written twice if you setup the DOT executable. You just need to remove the additional line:
Fixed.
4.) Having the possibility to view the HTML file in the internal HTML viewer of C::B would be really convenient, too. You can have a look how it's done in the build log.
This is now implemented. The internal viewer isn't capable enough to show all of the features that doxygen provides. The file list frame doesn't work, some links don't work, presumably for lack of JavaScript, and it doesn't support CSS, however I think it does enough to allow a reasonable preview of the compiled docs and avoid running a full browser, or just for a quick preview.
6.) The setup dialog is quite huge and although I personally don't really care I think users with small screen resolutions will complain sooner or later.
I spent some time reworking things to bring it back to the size that exists when DoxyBlocks isn't installed.
Hehe... I'll give you one more: When choosing to add a doxygen comment at the current cursor position you could parse the following code for a function signature and pre-process the lines added accordingly.
This is done, too. I spent quite some time researching the possibilities and looking at regexes. It seems that there is no way to reliably parse every possible code signature that might exist in C\C++ code. So far, I have done enough to allow it to scan the selected line when entering a block comment and pre-fill the params and return value. It makes some decisions regarding what to insert, based on what it finds. It is aware of enum, typedef, struct, class and functions with and without return values and with and without a class name prefix. It is, however, not yet coping with more than one return value keyword, such as "static char", or functions with parameters on separate lines, and there are other limitations. It seems to work fairly reliably with the standard range of function signatures. More can be done, in time, but this gives us a good starting platform. If it can't identify a particular signature it provides a default comment block. I will do some more wrestling with the regexes some time soon.
I will probably look at automating it across entire files. I'm not confident that it will work well enough, yet, or ever, to parse a whole document without making significant errors. A run that creates a lot of incorrect comment blocks would be worse, I think, than having to enter them separately. I intentionally haven't provided a means to enter a \brief entry by inserting something trivial such as the class or function name. I've seen other similar plugins that do this but, frankly, I find that meaningless. You would be much better off simply enabling EXTRACT_ALL and letting it pull out something meaningful rather than inserting text such as "myfunction" as the brief description for a function called "myfunction". Doing that just duplicates what already exists and describes nothing. The description should be just that, or left blank, I think. Anyway, we'll see what transpires.
Thanks for the input, I hope you like the results.
Cheers.