Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Plugins development => Topic started by: Cryogen on February 19, 2010, 05:31:57 am

Title: Doxygen plugin
Post by: Cryogen on February 19, 2010, 05:31:57 am
 Hi Guys,

I'd like to announce a new doxygen integration plugin. I call it DoxyBlocks.

I've loved and used doxygen (http://www.stack.nl/~dimitri/doxygen/ (http://www.stack.nl/~dimitri/doxygen/)) for years. I've used Doxbar under VS and missed a similar tool for C::B. Recently, I found jomeggs' doxygen script (http://forums.codeblocks.org/index.php/topic,8213.0.html (http://forums.codeblocks.org/index.php/topic,8213.0.html)), which works well but is somewhat limited, and was inspired to create a full plugin to replace it. Since doxygen is the C::B documentation tool of choice, it seemed even more appropriate.

DoxyBlocks provides a toolbar for quick access to documentation commands. It currently provides functionality which creates a doxyfile and extracts the docs, based on jomeggs script but fairly heavily modified. The converted code includes some extensions and some "tidying up" and adds functionality. DoxyBlocks can also insert block and line comments and run doxywizard for more detailed modifications of the doxyfile. It looks like this:

(http://cryogen.byethost24.com/snap.png)

and includes a configuration panel in the editor settings module. All comment types described in the doxygen docs are available.

I plan to add more functionality to allow configuration of the default settings that go into the doxyfile. It might also be useful to add the ability to insert other tag types manually and I plan to look into generating document blocks automatically. I have seen code around that does that. Other things are open for discussion.

The only thing I don't propose to do is write a full replacement for doxywizard. Doxywizard is more than capable and it seems futile to recreate the wheel. My intention is rather to provide reasonable default configuration with some common settings available and defer to doxywizard for the rest. For example, I'd like the user to be able to control things such as OUTPUT_LANGUAGE, EXTRACT_ALL, FULL_PATH_NAMES and ouput types.  With the right balance DoxyBlocks should be able to set things up for you most of the time and you should only need to use doxywizard for access to less common settings. At least that's my hope.

I'm still thinking about one or two things such as being able to enter a custom comment style to be used.

It is already quite usable and DoxyBlocks itself was documented using...DoxyBlocks. :-)

You can find the source by pointing SVN at: https://doxyblocks.svn.sourceforge.net/svnroot/doxyblocks (https://doxyblocks.svn.sourceforge.net/svnroot/doxyblocks).

The project page is at https://sourceforge.net/projects/doxyblocks/ (https://sourceforge.net/projects/doxyblocks/) and a cbplugin is available for download, too.

Thanks to jomeggs for the script and the inspiration.

Cheers,

  Gary.
Title: Re: Doxygen plugin
Post by: JGM on February 19, 2010, 06:16:22 am
Whoa really cool this is a feature that was really needed by codeblocks, a tool that facilitates documenting the code, great candidate to be part of nightly builds  8).

Thanks for your work :)
Title: Re: Doxygen plugin
Post by: Cryogen on February 19, 2010, 06:26:16 am

 Thanks, I appreciate that. I certainly hope it will be useful. I'm already finding it very helpful.

 :)
Title: Re: Doxygen plugin
Post by: killerbot on February 19, 2010, 10:14:56 pm
in case  this works well, might be interesting to add it to our contrib plug-ins section in our source tree, and provide it with the upcoming release :-)
I will test it out too.

Question : does it work under windows and linux ?
One thing that won't be able I think under linux is the creation of chm's.
Title: Re: Doxygen plugin
Post by: codeur on February 20, 2010, 07:24:06 am
Hi Cryogen,
The ".cbplugin" you provide fails to load with my current version built from a recent svn (6113).
Unfortunately I have no time currently to attempt to rebuild it for the current version, as (by looking at your project) your installation looks quite different and the project options would require a fair bit of editing, but I thought I'd let you know.
Title: Re: Doxygen plugin
Post by: Cryogen on February 22, 2010, 07:32:34 pm

 Hi Codeur,

Thanks for trying it. A .cbplugin is just a zip file with standard C::B paths in it. There is nothing specific to me in there. I have no idea why it would fail for you other than if things have changed since your version. If you'd like to provide some details such as exactly what fails and what messages you receive, that would be helpful.

Actually, this raises the question of whether a plug-in built with a recent SVN will run in 8.02. Does anyone know?

As for the source, it's built with SVN version 6130 so I'm wondering whether your version may not have recent features such as the extra code field in wxSmith, which you will definitely need. All paths are created using $(#cb) and $(#wx) so, again, there's nothing specific to me in there and (intentionally) no effort required on your part other than to have those variables set in your IDE. Other than that it's a bog standard, C::B-created plug-in project. :-) It does use the AutoVersion plug-in.

If you could provide the details and try upgrading your version and report your results that would be appreciated.

Thanks.
Title: Re: Doxygen plugin
Post by: Cryogen on February 22, 2010, 07:43:07 pm
 Hi Killerbot,

 Thanks.

I should know later today. That should answer the 8.02 question, too. The CHM is currently only run under windows and, as of the version I'm about to post, can be controlled by preferences. There are options for running CHMs under Linux. wxCHM, for example, or you may be able to do it under WINE. The plug-in itself should work without issues. Other than the one conditional call to run the CHM it's all platform-independent. The only problem might be if there have been some incompatible changes in the SVN code. I'll let you know.

Cheers,

  Cryo.
Title: Re: Doxygen plugin
Post by: Cryogen on February 22, 2010, 09:25:29 pm
 Hi Guys,

I've now uploaded a new version that adds quite a lot of new functionality:

22 February 2010
   released version 0.2.172 of DoxyBlocks

     Change log:
        -Fixed: Bug that stopped the "Run CHM" pref from working.
        -Fixed: Bug that stopped the "Project Number" pref from working.
        -Added: The ability to run the HTML and CHM from the toolbar.
        -Fixed: Bug that caused a crash when using the plugin without a project open.
        -Added: Doxyfile default prefs configuration.
        -Added: Access to configuration from toolbar.
        -Added: Ability to overwrite doxyfile either silently or after prompt.
        -Added: Option to control whether CHM is run after compilation.

I wasn't thinking before but I should point out that this version is only for Windows i.e. it's a dll. I'll be looking at Linux later today.

 Cheers.
Title: Re: Doxygen plugin
Post by: killerbot on February 22, 2010, 10:16:54 pm
Hi Killerbot,

 Thanks.

I should know later today. That should answer the 8.02 question, too. The CHM is currently only run under windows and, as of the version I'm about to post, can be controlled by preferences. There are options for running CHMs under Linux. wxCHM, for example, or you may be able to do it under WINE. The plug-in itself should work without issues. Other than the one conditional call to run the CHM it's all platform-independent. The only problem might be if there have been some incompatible changes in the SVN code. I'll let you know.

Cheers,

  Cryo.


in linux version would be nice to try to incorporate the wxchm (i don't knwo it, but it sounds interesting) :-)
Title: Re: Doxygen plugin
Post by: rcoll on February 23, 2010, 02:27:08 pm
in linux version would be nice to try to incorporate the wxchm (i don't knwo it, but it sounds interesting) :-)

A *.chm file is compiled HTML; does linux have a way of reading those?

Ringo
Title: Re: Doxygen plugin
Post by: Jenna on February 23, 2010, 03:26:43 pm
in linux version would be nice to try to incorporate the wxchm (i don't knwo it, but it sounds interesting) :-)

A *.chm file is compiled HTML; does linux have a way of reading those?

Ringo


Yes, several apps that can read chm-files are available on linux.
Title: Re: Doxygen plugin
Post by: JGM on February 24, 2010, 01:55:41 am
a chm file could be said it is a zip file with the files inside organized in a standar way
Title: Re: Doxygen plugin
Post by: codeur on February 24, 2010, 12:59:49 pm
Hi Codeur,
. . .
If you could provide the details and try upgrading your version and report your results that would be appreciated.
. . .

Thanks for trying to guess why I am having this issue. I do not myself have time to investigate this, so I am not asking for help on this.

Just to answer your question, The error I get when installing the .cbplugin is:
------------------------------------------------
"one or more plugins were not installed successfully:
G:\down\Program........\DoxyBlocks.cbplugin"
------------------------------------------------
A pop-up windows comes up from the task bar:
-------------------------------------------------------------
One or more plugin were not loaded.
This usually happen when a plugin is built for a different version
of the Code::Block SDK. Check the application log for more info.

List of failed plugins:
DoxyBlocks.dll
-------------------------------------------------------------

Obviously this does not tell us much new. (Except that it is an answer to your question: A plugin built from a recent svn is very unklikely to run in CB 8.02.)

It also tells me that upgrading my version would indeed probably fix the issue. I'll do that sometime, but don't hold your breath as this is an installation common to about 200 people. I do not change it just to install a new plugin, even one as useful as Doxygen.

Title: Re: Doxygen plugin
Post by: MortenMacFly on February 24, 2010, 01:12:14 pm
I've now uploaded a new version that adds quite a lot of new functionality:
22 February 2010
   released version 0.2.172 of DoxyBlocks
I gave it a try and it looks quite good. :P

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.
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.
3.) The "DOT_PATH" is written twice if you setup the DOT executable. You just need to remove the additional line:
Code
sText +=  _T("DOT_PATH               =\n");
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.
5.) The project file needs some clean up as there are absolute path's included that make installation fail. You should consider to put all path's relative to the "contrib" plugin folder. That's what most people expect I'd say.
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.

Besides this I just started using it and having fun. :)
Title: Re: Doxygen plugin
Post by: Cryogen on February 25, 2010, 09:31:18 pm

 Hi Guys,

Thanks for all of the discussion and feedback, much appreciated. Thanks, Morten, for the detailed response. I'll respond to that separately.

I have just uploaded V0.2.178. Changes since 172:

-Updated: Documentation.
-Fixed: Prefs dlg order and improved the layout slightly.
-Added: Warning checkbox toggles other warnings which I forgot to add before.
-Updated: The entire project to run from \src\plugins\contrib\. Hopefully that will solve some problems.

Note in particular that last, which speaks to one of Morten's comments.

Now then, I spent, or rather lost, an entire day (more like 16 hrs than 8!) trying to get the thing to run under Ubuntu and have ended up very frustrated. Firstly, the SVN version I built just won't run. It just hangs without output, even on the command line. I then spent hoooooooooooooours chasing down the solution to this error:

Quote
codeblocks: relocation error: /usr/lib/libcodeblocks.so.0: symbol _Z18wxSafeConvertWX2MBPKw, version WXU_2.8.2 not defined in file libwx_baseu-2.8.so.0 with link time reference

I have tried every solution that I could find, every package, repository, custom build, you name it. Nothing works and it then took me more hours to recover to 8.02. The only good that came from it is that I seem to have acquired a later version of wxSmith in the process which now has the Extra Code field that was stopping me before.

OK, so now I can build DoxyBlocks but will it run? No way. Not for anything. More wasted hours. It seems, from a comment of Jens', that there is an inherent problem with third-party plug-ins that causes the correct paths to be lost during start-up and therefore the thing fails looking for plug-in zip files. To say that I'm not impressed is an understatement.  :?

Result: I give up. I can build it and will post a version for others to try shortly but it seems that it won't run properly until such time as it's pre-built and supplied with C::B. That's just terrible. If anyone that knows more about this can help, that'd be great but it seems terminal thus far.

On to the good news. It installs and behaves as expected for me. There's a .cbplugin available now that was built from the C::B \src\ tree. I hope that that will remove some issues experienced by others. I have replaced the $(#CB) env. var., which I'm sure was provided by the project wizard, and used relative paths to be consistent with other plug-ins. It now only uses $(#WX), which should be standard with one exception. I have been unable to find any way to build wx with the "$(#WX.lib)\gcc_dll$" style path. After much searching, the only method I could get to work was creating my own dirs within the wx tree for each build, so I have this style of thing:

...\wxWidgets-2.8.10\msw-release-mono\lib\...

so the one path that I think you'll have to change is this one:

$(#wx.lib)\wx\include\msw-unicode-release-2.8

to this, I think:

$(#WX.lib)\gcc_dll$(WX_CFG)\msw$(WX_SUFFIX)

Again, if anyone would care to educate me on how to achieve the paths that C::B expects by default, that wold be good as I currently have to edit every instance which, you might say, is sub-optimal.  :)

Here's a new snapshot:

(http://cryogen.byethost24.com/snap2.png)

and, finally, the docs are now online at:

http://doxyblocks.sourceforge.net/ (http://doxyblocks.sourceforge.net/)

Cheers,

  Cryo.

Title: Re: Doxygen plugin
Post by: Jenna on February 25, 2010, 09:50:47 pm
Quote
codeblocks: relocation error: /usr/lib/libcodeblocks.so.0: symbol _Z18wxSafeConvertWX2MBPKw, version WXU_2.8.2 not defined in file libwx_baseu-2.8.so.0 with link time reference

This is a problem with the wxWidgets in Ubuntu 9.10, that is not binary compatible with the version of wxWidgets.org .
There are several posts about this, to fix the problem.

Nevertheless, I will see what I can do to build and run your plugin on linux .
Title: Re: Doxygen plugin
Post by: codeur on February 25, 2010, 10:39:32 pm
Hello Cryo/Gary,
I am not surprised that you got frustrated. There is a lot to know about CB, wxWidgets and the various releases of the different platforms that is hard to come by as it is lost in a huge amount of discussion on the forums. Documentation is definitely not crash hot. We need Doxygen!
Only long-time developers can navigate through this maze with some ease, and they may not fully understand the frustrations of a newcomer.
However do not bang your head against the wall for 16 hours again. Ask for help here. Your project is really useful and as you can see from the replies from jens and MMF, those long-timers are very willing to help a worthwhile cause.
I, for one am very grateful to you for trying so hard. I'll try building your new version on my Windows system.
Many thanks for this and for publishing the docs.
Title: Re: Doxygen plugin
Post by: Cryogen on February 25, 2010, 11:23:08 pm

 Hi Codeur,

Quote
Thanks for trying to guess why I am having this issue. I do not myself have time to investigate this, so I am not asking for help on this.

No probs.  8)

Quote
Just to answer your question, The error I get when installing the .cbplugin is:
...
One or more plugin were not loaded.
This usually happen when a plugin is built for a different version
of the Code::Block SDK. Check the application log for more info.
...
Obviously this does not tell us much new. (Except that it is an answer to your question: A plugin built from a recent svn is very unklikely to run in CB 8.02.)

Yes, you may have hit the nail on the head, there. If I'm lucky the imminent release will update whatever is required and this problem will go away. I love "if"s.  :lol:

Quote
It also tells me that upgrading my version would indeed probably fix the issue. I'll do that sometime, but don't hold your breath as this is an installation common to about 200 people. I do not change it just to install a new plugin, even one as useful as Doxygen.

Yup, I understand. That's a big group you have there!

Cheers.
Title: Re: Doxygen plugin
Post by: Cryogen on February 25, 2010, 11:42:38 pm

 Hi Morten,

Quote
I gave it a try and it looks quite good.

Oh, that's good. It's nice to know that someone has been able to run it.

Quote
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.

Fair comment. Funny what we assume, isn't it? Do you think that it would be best as a sub-menu in the Plugins menu or is it worthy of a new menu to itself?

Quote
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.

Sounds like a good idea.

Quote
3.) The "DOT_PATH" is written twice if you setup the DOT executable. You just need to remove the additional line:
Code:

 Thanks, I'll look into that and fix it.

Quote
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.

I hadn't thought of that as I don't use it but it sounds useful. What do you mean by "in the build log"?

Quote
5.) The project file needs some clean up as there are absolute path's included that make installation fail. You should consider to put all path's relative to the "contrib" plugin folder. That's what most people expect I'd say.

Done, as described in a previous post. If it can improve further, let me know.

Quote
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.

It's interesting that you say that because I have taken care NOT to enlarge the editor prefs window. Something may have slipped recently. I did some reorganising today, as well. I may split the doxyfile prefs across two tabs. I think that'll have to happen if I include any more default options, anyway.

Quote
Besides this I just started using it and having fun.

Cool, ta.

Thanks for the useful suggestions. Keep 'em coming. I want this to be useful to the community at large so I'm open to change.

Cheers.

Title: Re: Doxygen plugin
Post by: Cryogen on February 25, 2010, 11:53:47 pm
Quote
Hello Cryo/Gary,

Gary's fine. I don't use the tag, as such, it's just that my name and initials are never available when I have to register for things.

Quote
I am not surprised that you got frustrated. There is a lot to know about CB, wxWidgets and the various releases of the different platforms that is hard to come by as it is lost in a huge amount of discussion on the forums. Documentation is definitely not crash hot. We need Doxygen!

Yeeeees, the forums and good ol' Google are very useful but they don't always get you all of the way.

Quote
Only long-time developers can navigate through this maze with some ease, and they may not fully understand the frustrations of a newcomer.

That's pretty normal and it's why folks like me have jobs.  8)

Quote
However do not bang your head against the wall for 16 hours again. Ask for help here. Your project is really useful and as you can see from the replies from jens and MMF, those long-timers are very willing to help a worthwhile cause.

Yes, I know and appreciate that but I have two fundamental flaws. The first is that I am a stubborn git and determined to work things out. The second is that I'm impatient and dislike sitting around twiddling my thumbs waiting for forum responses (said with due deference to folks here, you can't expect rapid responses at times that suit you). I usually wait until I can't find anything else to try and have no choice before I do that, which is where I am now.  :lol:

Quote
I, for one am very grateful to you for trying so hard. I'll try building your new version on my Windows system.
Many thanks for this and for publishing the docs.

Thanks, jolly decent of you to say so and you're welcome. We'll get there between us, I have no doubt, but see flaw 2 above.  :P

Cheers,

  Gary.
Title: Re: Doxygen plugin
Post by: Cryogen on February 26, 2010, 12:04:16 am

 Hi Jens,

Quote
This is a problem with the wxWidgets in Ubuntu 9.10, that is not binary compatible with the version of wxWidgets.org .
There are several posts about this, to fix the problem.

Yes, I have tried them all, including your pages. :-)

Quote
Nevertheless, I will see what I can do to build and run your plugin on linux .

Thanks, that would be wonderful. If you can suggest how I should proceed on Ubuntu Karmic that would also be great.

Cheers.
Title: Re: Doxygen plugin
Post by: Jenna on February 26, 2010, 07:28:15 am
Thanks, that would be wonderful. If you can suggest how I should proceed on Ubuntu Karmic that would also be great.
Compiling on linux was no problem, I attach the project-file that works for me.
I did not (yet) test the functionality.

To use C::B on Karmic, you have to either remove all wxwidgets 2.8.10 packages shipped with ubuntu and use the ones from apt.wxwidgets.org (in this case you can use my repo), or remove all packages from apt.wxwidgets.org and use the packages shipped with Karmic.

In the second case you have to build C::B yourself with automake system or use the repo provided by pasgui (he provides a special version for Karmic) : http://forums.codeblocks.org/index.php/topic,11875.msg80825.html#msg80825 (http://forums.codeblocks.org/index.php/topic,11875.msg80825.html#msg80825) .

[attachment deleted by admin]
Title: Re: Doxygen plugin
Post by: MortenMacFly on February 26, 2010, 08:12:40 am
Fair comment. Funny what we assume, isn't it? Do you think that it would be best as a sub-menu in the Plugins menu or is it worthy of a new menu to itself?
Do an own one. (That's just my opinion.)

I hadn't thought of that as I don't use it but it sounds useful. What do you mean by "in the build log"?
If you write a HTML log file then in the build log a message (link) to the HTML log file appears which you can click. This opens the internal HMTL viewer of C::B. I meant have a look at the code how it's done.

I think that'll have to happen if I include any more default options, anyway.
Mmmh... I was under the impression that the stand-alone config dialog was that big... probably it was the container - I'll have another look

Keep 'em coming. I want this to be useful to the community at large so I'm open to change.
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. Meaning: If I choose to add the comment before a line like:
Code
int MyFunc(double par1, int par2);
...it could add the params and the return value automatically. like:
Code
/**
 * \brief MyFunc
 * \param par1
 * \param par2
 * \return
 */
...whereas for:
Code
void MyFunc();
...it would just add:
Code
/**
 * \brief MyFunc
 */
Surely this is a bit complicated but would save some time typing. :lol:
Title: Re: Doxygen plugin
Post by: Cryogen on February 26, 2010, 07:41:58 pm

 Hi,

Quote
If you write a HTML log file then in the build log a message (link) to the HTML log file appears which you can click. This opens the internal HMTL viewer of C::B. I meant have a look at the code how it's done.

Aah, is that what that is for. I've clicked on some and nothing happens. I just tried again after running HTML docs, which produces said link, still nothing. I couldn't find any HTML viewer in the menus but then I saw that the man viewer's title bar actually says "Man/HTML". Is that it? Either way it doesn't work for me in SVN 6130. Or I haven't found it.  :)

Quote
Mmmh... I was under the impression that the stand-alone config dialog was that big... probably it was the container - I'll have another look

I checked too with and without the plug-in installed. It has slipped a bit and become larger. I think I can restore it to the original size by splitting across tabs.

Quote
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.

In fact I hope to go one step further than that. I'd like it to be able to document the project automatically. I've seen code around that does that. I think it will require some dabbling in regexes, which I'm no expert with but, if I can get that working, this would be a logical contraction of that. Thanks.

Cheers.
Title: Re: Doxygen plugin
Post by: Cryogen on February 26, 2010, 08:22:21 pm
Thanks, that would be wonderful. If you can suggest how I should proceed on Ubuntu Karmic that would also be great.
Compiling on linux was no problem, I attach the project-file that works for me.
I did not (yet) test the functionality.

 Yeah, I can build it, too. I just can't run it in any way. Thanks for that I'll compare it with mine and see what shows up.

Quote
To use C::B on Karmic, you have to either remove all wxwidgets 2.8.10 packages shipped with ubuntu and use the ones from apt.wxwidgets.org (in this case you can use my repo), or remove all packages from apt.wxwidgets.org and use the packages shipped with Karmic.

Yes, I did that. Something may have been out of place so I'll give it another go and report progress.

Quote
In the second case you have to build C::B yourself with automake system or use the repo provided by pasgui (he provides a special version for Karmic) : http://forums.codeblocks.org/index.php/topic,11875.msg80825.html#msg80825 (http://forums.codeblocks.org/index.php/topic,11875.msg80825.html#msg80825) .

My build hangs as described. Reason unknown. pasgui's repo didn't work either. As I said I tried eeeeeeeeverything. :?
However, there's every chance I screwed things up. I can get around on Linux without trouble but I don't have the same depth of knowledge that I do with Winblows systems. For example, is the installation order critical? Is there anything I need to ensure happens a certain way at some stage?

Cheers.
Title: Re: Doxygen plugin
Post by: Cryogen on March 01, 2010, 02:41:09 am
Quote
To use C::B on Karmic, you have to either remove all wxwidgets 2.8.10 packages shipped with ubuntu and use the ones from apt.wxwidgets.org (in this case you can use my repo), or remove all packages from apt.wxwidgets.org and use the packages shipped with Karmic.

Yes, I did that. Something may have been out of place so I'll give it another go and report progress.


OK, I spent several more hours going through this. I had some things set up wrong. I rebuilt wx as a monolithic lib and downloaded the latest SVN, 6182, and built it manually via make, make install, etc. It now runs BUT, the plug-in doesn't. I built the plug-in from within the contrib dir. It won't install and suggests that this happens when a plug-in is built for a different version of the sdk. No, I don't think so. I guess that this might be because it wants to run with a version that is running in the same src tree, although I can't see why. So, I run C::B and then build it with C::B to generate src/devel/... I then run "update"  to generate src/ouput/... and the run scripts, etc. However, when I try to run either the debug or release versions that I built, they stop at:

Code
gary@ubuntu:~/Projects/CodeBlocks/src/output$ ./run.sh 
Initialize EditColourSet .....
Initialize EditColourSet: done.
Loading toolbar...
DoxyBlocks: loaded
AutoVersioning: loaded
BYOGames: loaded
cbDragScroll: loaded
DoxyBlocks plugin activated
AutoVersioning plugin activated
BYO Games plugin activated
DragScroll plugin activated
Initializing plugins...

The same thing happens if DoxyBlocks isn't present so it seems to be something other than my plug-in, which is a nice change at least, but what? They should all be using the same wx libraries so I can't see where the difference could be. I'm frankly stumped as to how one is supposed to get to the stage where this can work. How can I have my dev. installation in parallel with the make-generated and -installed version? Is that even how things should be? The build doc is unclear and documentation in general is scarce. I've spent hours in the forums and elsewhere and still can't make a simple plug-in run here. I have everything working well on Windows, so I have a good idea of what's required but this is just driving me nuts.

Now I'm going to have a bitch. While I greatly appreciate the work that goes into it and accept that I'm no guru on Ubuntu, ain't no-one going to to persist as long as I have to try and get this thing to work. It needs to be sorted out, and quickly, so that the average joe that comes along and wants to build it can do so. Otherwise we're all wasting our time, aren't we? Someone who can deal with these problems needs to provide some canonical methodology to get it to work. For everyone. Ubuntu is the most popular distribution around so we have to have it working smoothly there or we're going to lose a lot of users to the myriad other options that are available these days. And what's going to happen if I want to upgrade to Lucid? There's no sense in trying to use a cross-platform system if the IDE you need to run to do so won't run as required across platforms. I'm happy to be part of the solution but can someone who knows what required PLEASE supply some detailed steps to allow me to run my own plug-in in my own build of C::B before I go insane? Having done all of the legwork just to get it to build and run anything I build should just run and this should be trivial, really, but it's not.

My failing sanity thanks you in advance.

I'm off to therapy. Back soon.  :shock:

Title: Re: Doxygen plugin
Post by: Cryogen on March 01, 2010, 02:53:35 am

 Hi Guys,

I'm back from therapy, now.  8)

I have uploaded version 0.3.287.

-Fixed: DOT_PATH was written twice due to some extraneous code.
-Added: New menu which mirrors toolbar functionality.
-Added: Context-sensitive menu.
-Added: Translation catalogue.
-Cleaned: Some general code tidying.
-Added: Resource file and Windows version info.

There is now a linux .cbplugin for you to try. As you have probably gathered by now, I can't run it on Linux. If you can please let me know.

 Gary.
Title: Re: Doxygen plugin
Post by: Cryogen on March 03, 2010, 08:11:15 am

 Hi Guys,

Released version 0.5.457 of DoxyBlocks

     Change log:
        -Added: BusyInfo when running doxygen.
        -Added: Ability to run HTML after compilation.
        -Added: Ability to run HTML in the internal viewer.
        -Updated: Header blocks for all files.
        -Added: Now parses the selected line when inserting block comments and pre-fills the \param and \return values.
        -Added: Option to use "@" in comments rather than "\".

Cheers.
Title: Re: Doxygen plugin
Post by: Cryogen on March 03, 2010, 08:45:57 am

 Hi Morten,

Quote
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.

Quote
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.

Quote
3.) The "DOT_PATH" is written twice if you setup the DOT executable. You just need to remove the additional line:

Fixed.

Quote
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.


Quote
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.

Quote
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.

Title: Re: Doxygen plugin
Post by: Cryogen on March 05, 2010, 09:28:52 pm

 Hi,

I have uploaded V0.7.636 to the SVN repository.

Change log:
-Added: Added the ability to use the AutoVersion plug-in's version string as doxygen's project number value.
-Fixed: The function parser was creating comments with the parameter type and name in the wrong order.
-Fixed: Bug in regex pattern matching that allowed multiple matches.
-Added: Inserted comments blocks are now indented to match the code that they're commenting.

Cheers.
Title: Re: Doxygen plugin
Post by: MortenMacFly on March 05, 2010, 09:55:38 pm
-Added: Inserted comments blocks are now indented to match the code that they're commenting.
Can't wait testing... :-)

Looks REALLY good so far... Good work! :P
Title: Re: Doxygen plugin
Post by: codeur on March 05, 2010, 11:56:24 pm
DoxyBlocks builds in the trunk development environment, except that it attempts to link with -lwx_mswu-2.8.dll which is not in my system. I have to link with -lwxmsw28u (wxmsw28u.dll which I have) instead. Once I link it this way, it runs OK in the trunk version of CB (still cannot get it to load in our svn 6113 production system unfortunately, but I am getting closer).

I am totally unfamiliar with CB development so I have this newbie question for you Gary: is "libwx_mswu-2.8.dll.a" or "wx_mswu-2.8.dll" a file we are supposed to obtain from building the wxwidgets or during their installation?

BTW: I am impressed by the amount of work you have produced for this doxygen plugin in this short time... and you are a perfectionist, fixing details before they are mentioned to you. I am feeling quite awed really, thanks.
Title: Re: Doxygen plugin
Post by: private_joker on March 06, 2010, 02:56:43 am
Bug: if tabs w. sourcecode isn't open and you trying push "Extract documentation..." button, CB will crash.

Bug: ExtractDocs.cpp:551

Code
ret = wxExecute (cmd + wxT(" ") + fnDoxyfile.GetFullPath(), sOutput, sErrors);
if(ret == 0)
 {}

Quote
Execution of 'C:\Program Files\doxygen\bin\doxygen.exe' failed.

It seems like "if(ret == 0)" isn't fully correct. Maybe better use "if(ret != -1)"

Probably Bug: doxywizard isn't run.

Quote
Running doxywizard...
Process 3308 (C:\Program Files\doxygen\bin\doxywizard.exe C:\Program Files\CodeBlocks\workspace\Codeblocks-Nightly\src\plugins\contrib\doxyblocks\doxygen\doxyfile) launched.

I'm using self builded CB and self builded Doxyblocks. Both from SVN trunk.

Thank you & keep working on it.


Title: Re: Doxygen plugin
Post by: Cryogen on March 06, 2010, 08:31:13 pm

  Hey Codeur,

DoxyBlocks builds in the trunk development environment, except that it attempts to link with -lwx_mswu-2.8.dll which is not in my system. I have to link with -lwxmsw28u (wxmsw28u.dll which I have) instead. Once I link it this way, it runs OK in the trunk version of CB (still cannot get it to load in our svn 6113 production system unfortunately, but I am getting closer).

That sounds fine. There are still some subtleties of building in C::B that I haven't yet mastered. I tried removing ".dll" from my build settings and it builds just fine. I can see from the output that it links to the same file. C::B does have a system that adds prefixes and suffices to library names. The ".dll" is obviously unnecessary. Much of what I have set up is garnered from other plug-ins. Looking at the latest SVN, I see that plug-ins are set up with the lib described like this : "wxmsw28$(WX_SUFFIX)" where WX_SUFFIX = "u". I am gradually homing in on the correct settings to match the default set in the C::B code but I still have the problem that I have been unable to find any way to build wx with the "gcc_dll" style path. Until I can get that set up I won't be able to match C::B exactly, however I think that this is mostly obscured by the $(WX) variable. I will look at improving my library naming scheme as per the contrib plug-ins.

I haven't tried anything below 6130 and I'm now using 6182.  :)

I am totally unfamiliar with CB development so I have this newbie question for you Gary: is "libwx_mswu-2.8.dll.a" or "wx_mswu-2.8.dll" a file we are supposed to obtain from building the wxwidgets or during their installation?

When you build the plug-in, it links with your build of wx, i.e. you need to either build it yourself or download some pre-compiled libs. See http://wiki.codeblocks.org/index.php?title=Compiling_wxWidgets_2.6.2_to_develop_Code::Blocks_%28MSW%29 (http://wiki.codeblocks.org/index.php?title=Compiling_wxWidgets_2.6.2_to_develop_Code::Blocks_%28MSW%29). It's a bit out of date re: wx but still useful. I heartily recommend building it as it gives you much more control. C::B will prefix "libwx_" and postfix ".a" (and apparently ".dll") to the name in build settings so you should only need to enter "wx_mswu-2.8". The one thing I'm not certain of yet is whether "wxmsw28$(WX_SUFFIX)" expands to "mswu-2.8" or "msw-2.8u". I will find out shortly.  :wink:

BTW: I am impressed by the amount of work you have produced for this doxygen plugin in this short time... and you are a perfectionist, fixing details before they are mentioned to you. I am feeling quite awed really, thanks.

Thanks.  8)
Coding is "what I do" so I like it and this is my pet project at the moment. And yes, I'm a perfectionist.
I'm using it every day, as well, so it gets a good workout.

Cheers.
Title: Re: Doxygen plugin
Post by: Cryogen on March 06, 2010, 09:12:43 pm
-Added: Inserted comments blocks are now indented to match the code that they're commenting.
Can't wait testing... :-)

Looks REALLY good so far... Good work! :P

Thanks Morten. I'm hoping to get it into the contrib collection so please let me know if there is anything I need to do before that can happen e.g. setup, standards, build settings, etc.

I still have a couple of things in mind. I have realised that the current configuration scheme won't work well across projects. All settings are global at the moment which means that settings such as project version, comment style, doxyfile defaults, etc., which should be per-project settings, will carry over to subsequent projects. I am going to change that today so that those items are stored per-project in the .cbp. Settings such as paths to executable files can and should remain global.
I would also like to look at automating comment insertion across whole files and, if that's practical, perhaps across whole projects. That does raise some issues, though, such as how to differentiate between a function definition in a .cpp and the prototype in a .h and avoid commenting them both. My current thinking is that commenting a whole file is probably as far as I should go.
I also want to improve the regexes. I have detection of multiple return vals working in the regex testbed but it fails in the code. I don't understand that as the testbed is built with the same wx and therefore uses the same function calls. Any ideas?

Cheers,

  Gary.
Title: Re: Doxygen plugin
Post by: Cryogen on March 06, 2010, 09:17:36 pm

 Hi Guys,

I have been tinkering with some of the other plug-ins in my travels around C::B, as well. Of note is that I have added a new comment type to the ToDo plug-in to allow it to insert "\todo" lines directly into C-style doxygen blocks. The existing C++-type doxygen-style comment already does this well for C++-styled comments but none worked for C-styled blocks. The details are here:
http://forums.codeblocks.org/index.php/topic,12130.0.html (http://forums.codeblocks.org/index.php/topic,12130.0.html)

Cheers.
Title: Re: Doxygen plugin
Post by: Cryogen on March 06, 2010, 10:32:00 pm

  Hey Joker,

Thanks for taking the time to report your findings, I really appreciate it.

Bug: if tabs w. sourcecode isn't open and you trying push "Extract documentation..." button, CB will crash.

Whoa doctor! That's not good. I've looked into this. In fact, the only button that does not crash C::B when there are no tabs open is the config. dialogue button. My code is never executed i.e. C::B crashes before it gets to my code. I can't trap it. I think that the config button may work because it uses a default plug-in function. Execution doesn't reach the first line of the function called by connect() to respond to the event. Morten, can you shed any light on this?

In the meantime the workaround is to ensure that you have at least one editor window open when running DoxyBlocks functions.

Bug: ExtractDocs.cpp:551

Code
ret = wxExecute (cmd + wxT(" ") + fnDoxyfile.GetFullPath(), sOutput, sErrors);
if(ret == 0)
 {}

Quote
Execution of 'C:\Program Files\doxygen\bin\doxygen.exe' failed.

It seems like "if(ret == 0)" isn't fully correct. Maybe better use "if(ret != -1)"

From the docs: "In the case of synchronous execution, the return value is the exit code of the process (which terminates by the moment the function returns) and will be -1 if the process couldn't be started and typically 0 if the process terminated successfully."
I take your point. != -1 does seem to be more correct.  I've changed it, thanks. Are you seeing a problem? You don't say.

Probably Bug: doxywizard isn't run.

Quote
Running doxywizard...
Process 3308 (C:\Program Files\doxygen\bin\doxywizard.exe C:\Program Files\CodeBlocks\workspace\Codeblocks-Nightly\src\plugins\contrib\doxyblocks\doxygen\doxyfile) launched.

So you're seeing this message and then doxywizard doesn't appear? I'd say if a process number is returned then it ran. What happens after the process is spawned is not C::B's doing. I see, however, that you are using the notorious "Program Files" directory and I would guess that the space in the path is choking doxywizard. I would recommend never using Program Files for anything of your own and leaving it for Windows' use. Since doxygen is originally a Unix application I would think that it doesn't like spaces.

[Update:] I ran a check and, sure enough, doxywizard fails if I use a path to a doxyfile that contains spaces. DoxyBlocks should quote the path to avoid the problem. I'll fix that and upload it to SVN later today. Thanks.

I'd appreciate an update once you've tried it to let me know whether that fixes it for you.

I'm using self builded CB and self builded Doxyblocks. Both from SVN trunk.

Thank you & keep working on it.

Thanks. You can count on it.   :P
Title: Re: Doxygen plugin
Post by: Cryogen on March 06, 2010, 10:58:46 pm

Uploaded 0.7.670. SVN revision 12.

Change log:
-Added: The block comment sample now updates to reflect the selection when "Use @ In Tags" selection is changed.
-Cleaned: Improved some text generation to simplify localisation strings.
-Added: Some missing documentation.
-Updated: Improved return value checking when running doxygen. Thanks to private_joker.
-Updated: Quoted the doxyfile path when running doxywizard to avoid doxywizard crash if the path contain spaces. Thanks to private_joker.

Cheers.
Title: Re: Doxygen plugin
Post by: private_joker on March 07, 2010, 12:32:48 am

  Hey Joker,

Thanks for taking the time to report your findings, I really appreciate it.

No problem, I'd want too to comment my code, normally is look like:

// don't know how, but it works, thank you God. Amen.
 :P

From the docs: "In the case of synchronous execution, the return value is the exit code of the process (which terminates by the moment the function returns) and will be -1 if the process couldn't be started and typically 0 if the process terminated successfully."
I take your point. != -1 does seem to be more correct.  I've changed it, thanks. Are you seeing a problem? You don't say.

Now is working.

So you're seeing this message and then doxywizard doesn't appear? I'd say if a process number is returned then it ran. What happens after the process is spawned is not C::B's doing. I see, however, that you are using the notorious "Program Files" directory and I would guess that the space in the path is choking doxywizard. I would recommend never using Program Files for anything of your own and leaving it for Windows' use. Since doxygen is originally a Unix application I would think that it doesn't like spaces.

[Update:] I ran a check and, sure enough, doxywizard fails if I use a path to a doxyfile that contains spaces. DoxyBlocks should quote the path to avoid the problem. I'll fix that and upload it to SVN later today. Thanks.

Yep. Now is working too.


I know it sounds a bit pedantic but:

ExtractDocs.cpp:565

Code
if(sText.Length() > 0)

I think
Code
if(!sText.IsEmpty())
is better  :)


Title: Re: Doxygen plugin
Post by: PizzaNapoli on March 07, 2010, 01:17:59 pm
Hi, everybody

I have the same problem as "codeur" in "Reply #12".

Unfortunately I can't install that plugin.

I use this CB version: Release 8.02 (2008-02-27 19:55:16) gcc 4.2.1 Windows/unicode on a Windows XP SP2

Now I'm not sure if this problem was solved, and if yes how ?

Title: Re: Doxygen plugin
Post by: MortenMacFly on March 07, 2010, 05:23:47 pm
I'm hoping to get it into the contrib collection so please let me know if there is anything I need to do before that can happen e.g. setup, standards, build settings, etc.
There is:
- The project files need some clean-up (I did this already and can provide you with a patch).
- The update files need some cleanup (do not create a "*.cbplugin" file as contrib plugin)
- It needs to be compilable under Linux using automake, so the "makefile.am's" are missing
- Do not include sdk_precomp.h directly, this is only correct for the core of C::B. Instead, include sdk.h
- I didn't verify the include statements of the plugin so far and whether they are correct in terms of PCH. However, here are the rules that need to apply:
http://wiki.codeblocks.org/index.php?title=Precompiled_headers

However, these are only minor things. Basically the lacking automake is currently the major show-stopper.
Title: Re: Doxygen plugin
Post by: Jenna on March 07, 2010, 05:38:03 pm
However, these are only minor things. Basically the lacking automake is currently the major show-stopper.

I hope I find the time to create it this evening and post the patch here (Just for the automake, nothing else, due to lack of time).
Title: Re: Doxygen plugin
Post by: Jenna on March 08, 2010, 05:18:09 am
However, these are only minor things. Basically the lacking automake is currently the major show-stopper.

I hope I find the time to create it this evening and post the patch here (Just for the automake, nothing else, due to lack of time).

I attached a patch containing the needed stuff for automake and debian (not for rpm-based distros).
The DoxyBlocks sources have to be in "src/plugins/contrib/DoxyBlocks" (the CamelCase is important, otherwise the files have to be fixed accordingly).

[attachment deleted by admin]
Title: Re: Doxygen plugin
Post by: Cryogen on March 10, 2010, 06:19:34 am
...
Now is working.
...
Yep. Now is working too.

Excellent, thanks.

I know it sounds a bit pedantic but:

ExtractDocs.cpp:565

Code
if(sText.Length() > 0)

I think
Code
if(!sText.IsEmpty())
is better  :)

Roger, thanks.
Title: Re: Doxygen plugin
Post by: Cryogen on March 10, 2010, 06:22:38 am
 
  Hey there,

I have the same problem as "codeur" in "Reply #12".

Unfortunately I can't install that plugin.

I use this CB version: Release 8.02 (2008-02-27 19:55:16) gcc 4.2.1 Windows/unicode on a Windows XP SP2

Now I'm not sure if this problem was solved, and if yes how ?

As noted in another post, I think there is little chance of it working in vanilla 8.02. You will probably need to build C::B yourself to get it working, at this stage. There's plenty of help here in the forum and on the wiki to get you going.

Cheers,

  Gary.


Title: Re: Doxygen plugin
Post by: Cryogen on March 10, 2010, 06:28:46 am
I'm hoping to get it into the contrib collection so please let me know if there is anything I need to do before that can happen e.g. setup, standards, build settings, etc.
There is:
- The project files need some clean-up (I did this already and can provide you with a patch).

Thanks, please do.

- The update files need some cleanup (do not create a "*.cbplugin" file as contrib plugin)

Yeah, that's just for me while I'm working on it. It's much easier to install a .cbplugin than going through the whole compile, exit, update, run routine every time I make a change. I can't debug directly as gdb fails. I'll remove it at the appropriate juncture. :-)

- It needs to be compilable under Linux using automake, so the "makefile.am's" are missing

About which I know nothing, I'm afraid.

- Do not include sdk_precomp.h directly, this is only correct for the core of C::B. Instead, include sdk.h

Fixed.

- I didn't verify the include statements of the plugin so far and whether they are correct in terms of PCH. However, here are the rules that need to apply:
http://wiki.codeblocks.org/index.php?title=Precompiled_headers

Oh good, ta, I was wondering about that. I'll look into it.

Cheers.
Title: Re: Doxygen plugin
Post by: Cryogen on March 10, 2010, 07:24:29 am
 Hi Guys,

Version 1.0.1 is now available. Changes:

-Fixed: Bug that slipped through preventing loading of some prefs.
Version 1.0.0:
-Added: Disable comment toolbar buttons and menu items when there are no editors open.
-Added: Changed the config system to use the project file and load and save at project open and close.
-Fixed: Bug in config. panel that allowed dependent warning checkboxes to be active when the master warnings one wasn't.

This version breaks compatibility with the configuration system prior to 1.0. you will just need to reset your preferences.

The change to per-project prefs is a significant change and improvement.

DoxyBlocks now handles multiple projects but it doesn't yet write documentation to discrete directories for each project. If you have multiple projects in the same directory, the docs will be written to the same doxygen folder, which will overwrite any that already exist of the same kind and mix the rest. This may be OK, depending on how you organise things. Document management for multiple projects in one directory will be forthcoming.

Multiple projects in the same workspace that reside in different directories should be handled as expected.

Cheers.

Title: Re: Doxygen plugin
Post by: Cryogen on March 10, 2010, 07:28:16 am
Bug: if tabs w. sourcecode isn't open and you trying push "Extract documentation..." button, CB will crash.

Whoa doctor! That's not good. I've looked into this. In fact, the only button that does not crash C::B when there are no tabs open is the config. dialogue button. My code is never executed i.e. C::B crashes before it gets to my code. I can't trap it. I think that the config button may work because it uses a default plug-in function. Execution doesn't reach the first line of the function called by connect() to respond to the event. Morten, can you shed any light on this?

In the meantime the workaround is to ensure that you have at least one editor window open when running DoxyBlocks functions.

Morten, Jens, any help with this?

Thanks.

Title: Re: Doxygen plugin
Post by: Cryogen on March 11, 2010, 08:56:31 am

 Today's excitement  :D :

Released version 1.0.14 of DoxyBlocks
-Added: Precompiled headers for faster compilation.
-Fixed: I somehow lost the wxSmith block from the project file.
-Added: The ability to run a CHM on any OS, given the appropriate viewer. Windows still uses the OS viewer by default.
-Added: Jens' automake files and added the missing files.
-Updated: Improved and added to the documentation.

There is a Linux .cbplugin available for download again. Apologies for the absence thereof in recent releases. I'm still interested to hear whether anyone has actually been able to run it, either from the .cbplugin or by compiling from source, on Linux.

Cheers.
Title: Localisation
Post by: Cryogen on March 11, 2010, 09:27:29 pm
 Could someone with the know-how advise me about localising plug-ins, please? Is the instruction found in another thread:

 
Quote
Drop the .mo files into $SHARE/codeblocks/locale/lang_CODE  and Code::Blocks will use them.

still correct? I ask because that directory doesn't exist for me and there are no .mo files in my src tree but that may be because I have the English version.

Also, how are the plug-ins translated? Launchpad seems only to have the IDE, or are the plug-ins' text merged with that somehow? What about third-party plug-ins??

Thanks.
Title: Re: Doxygen plugin
Post by: codeur on March 11, 2010, 10:52:10 pm

 Today's excitement  :D :

Released version 1.0.14 of DoxyBlocks
-...

I notice furious activity still going on SourceForge since, with version 15 in SVN.
Many thank.
Title: Re: Localisation
Post by: MortenMacFly on March 12, 2010, 09:23:14 am
Quote
Drop the .mo files into $SHARE/codeblocks/locale/lang_CODE  and Code::Blocks will use them.
still correct?
Yes, that is correct. And yes: This directory does not exist in the nightlies.
Title: Re: Localisation
Post by: Cryogen on March 12, 2010, 07:55:23 pm
Quote
Drop the .mo files into $SHARE/codeblocks/locale/lang_CODE  and Code::Blocks will use them.
still correct?
Yes, that is correct. And yes: This directory does not exist in the nightlies.

OK, thanks. Or the SVN repo, apparently, where I would have thought you'd expect to see the directory and a usage note, or something, no? I've never used a nightly build.

Could I also ask that you go back and answer the various other questions that I'm awaiting answers for? I know you've probably got 50 other things to think about here but I really need some answers.

E.g.
The whole Linux plug-in thing.
The problem with the toolbar crashing C::B when no editors are open.
Your project patch.
The other localisation questions.

Many thanks.
Title: Re: Doxygen plugin
Post by: Cryogen on March 16, 2010, 08:04:01 pm

 Hi Guys,

Released version 1.1.79 of DoxyBlocks
-Added: The toolbar and menu are now disabled when all projects are closed and re-enabled when a project is opened.
-Fixed: The wxSmith block was being lost from the .cbp when saving during project closure. Reworked how config is saved.

I also spent some time looking into automating the documentation of a file and found that it was not practical as things stand. There is currently no way to differentiate adequately between a function declaration and a function call, or stop it trying to document every macro declaration or other entry that looks like a documentable entity in the file. Better regexes would go some way towards improving things but it's always going to be a mixed bag. Since, other than when retrofitting existing code, we are encouraging people to document code as it's written, I don't see this as a big issue and that's where I'm going to leave it for now.
Title: Re: Doxygen plugin
Post by: codeur on March 16, 2010, 08:32:30 pm
Hi Guys,
... automating the documentation of a file and found that it was not practical as things stand. ...

Agreed. I use CB in an educational setting and would look pretty dimly at per-file documentation automation. It would mess up already written function banner comments and would encourage the poor practice of "commenting when all is done". I am glad you don't consider it anymore.
Title: Re: Doxygen plugin
Post by: codeur on March 16, 2010, 11:10:21 pm
...
-Added: The toolbar and menu are now disabled when all projects are closed and re-enabled when a project is opened.

There is something wrong with this (in my own Windows built that completes with 0 error 0 warning, I have not tried your .cbplugin). The menu and toolbar are disabled (greyed) when I close projects, but they are enabled when CB starts next on the "start here" screen (and no project loaded).  CB then dies some time afterwards. I have to uninstall doxyblocks to retrieve normal behaviour. The previous version was not doing this even though it would somehow kill CB if you tried to configure doxyblocks with no project open.
Title: Re: Doxygen plugin
Post by: LordCB on March 17, 2010, 01:32:05 am
I think I have forgotten how to install a plugin. I cant install this plugin
Title: Re: Doxygen plugin
Post by: Cryogen on March 17, 2010, 04:24:05 am
I notice furious activity still going on SourceForge since, with version 15 in SVN.
Many thank.

No problem. Glad you're still interested.  :P
Title: Re: Doxygen plugin
Post by: Cryogen on March 17, 2010, 04:32:13 am
Hi Guys,
... automating the documentation of a file and found that it was not practical as things stand. ...

Agreed. I use CB in an educational setting and would look pretty dimly at per-file documentation automation. It would mess up already written function banner comments and would encourage the poor practice of "commenting when all is done". I am glad you don't consider it anymore.

Yeah, you make a good point. As things are it would insert comments before the function, which would probably be between the function and any existing comments but, yes, I did think about the difficulty of detecting things like that and how much effort would be required to get even a half-way decent result. Assuming that even that could be achieved. Thanks for the comment.

Cheers,

  Cryo.
Title: Re: Doxygen plugin
Post by: Cryogen on March 17, 2010, 04:34:22 am
I think I have forgotten how to install a plugin. I cant install this plugin

Thanks for your interest. You can try Plugins\Manage plugins... and install the .cbplugin. Failing that I'm going to need some decent details.  :wink:

Cheers.
Title: Re: Doxygen plugin
Post by: Cryogen on March 17, 2010, 04:39:18 am
 Hey Codeur,

...
-Added: The toolbar and menu are now disabled when all projects are closed and re-enabled when a project is opened.

There is something wrong with this (in my own Windows built that completes with 0 error 0 warning, I have not tried your .cbplugin). The menu and toolbar are disabled (greyed) when I close projects, but they are enabled when CB starts next on the "start here" screen (and no project loaded).  CB then dies some time afterwards. I have to uninstall doxyblocks to retrieve normal behaviour. The previous version was not doing this even though it would somehow kill CB if you tried to configure doxyblocks with no project open.

Hmmm, OK. Please try the latest version. There was a problem with saving prefs that I have just fixed. Failing that, I'll need some steps that I can replicate because I'm not seeing that in my latest builds. As you can see below I have added some additional behavior around enabling and disabling the toolbar.

Also, for reference, I use the .cbplugin. I will go and try building it into debug and using update and see what happens after that, just to see if that changes things.

Cheers.

UPDATE: 1.1.111 is behaving normally after a rebuild and update in Windows SVN 6182 and the toolbar appears to be enabled/disabled appropriately now.

Title: Re: Doxygen plugin
Post by: Cryogen on March 17, 2010, 04:44:43 am

 I'm over-achieving today.  8)

Released version 1.1.111 of DoxyBlocks
-Updated: Made a matching HTML Help icon.
-Added: Block comments can now handle more than one return value keyword.
-Added: The toolbar is now disabled if there are no projects open on startup.
-Updated: Changed the log output when doxygen is running slightly.

Cheers.

Title: Re: Doxygen plugin
Post by: LordCB on March 17, 2010, 11:43:02 am
Ok, I use NB 6181 for error please look at attachment thanx in advance

[attachment deleted by admin]
Title: Re: Doxygen plugin
Post by: codeur on March 17, 2010, 12:58:35 pm
Ok, I use NB 6181 for error please look at attachment thanx in advance

Same here. I even built svn 6190 in order to see if it improved things. It does not.
However I have always had this very same error (same one as LordCB) with Gary's .cbplugins. I have to rebuild doxyblocks myself to get it to work.

The current svn update claims to be 1.1.79 (1.1.111 not committed?). It builds and loads OK when I build it myself with SVN 6190 (after some minor modifications to the project).

What I get though with version 1.1.79 still has the same problem that the menu and toolbar are active when CB is just started (and CB dies if you open the DoxyBlocks preferences without a project open and then click OK), so I'll wait until 1.1.111 or later is committed to svn to see if Gary's fix worked.
Title: Re: Doxygen plugin
Post by: Cryogen on March 17, 2010, 06:28:50 pm

 Hi Guys,

Ok, I use NB 6181 for error please look at attachment thanx in advance

Same here. I even built svn 6190 in order to see if it improved things. It does not.
However I have always had this very same error (same one as LordCB) with Gary's .cbplugins. I have to rebuild doxyblocks myself to get it to work.

The current svn update claims to be 1.1.79 (1.1.111 not committed?). It builds and loads OK when I build it myself with SVN 6190 (after some minor modifications to the project).

What I get though with version 1.1.79 still has the same problem that the menu and toolbar are active when CB is just started (and CB dies if you open the DoxyBlocks preferences without a project open and then click OK), so I'll wait until 1.1.111 or later is committed to svn to see if Gary's fix worked.


It looks like I neglected to commit 1.1.111. Sorry about that.  :oops:
It's committed now. That should fix the toolbar issue.

The error is interesting as that's exactly what I get when I try to install the Linux .cbplugin. The only things I can think of are that there is still something about my setup that is not as C::B expects or there's something wrong with the plug-in system. Since no-one seems to want to tell me what to do about it I can't do much. No-one seems to be using them, either, so maybe there's a reason for that. Interestingly, my Linux installation is the one that should be absolutely standard. It's the Windows one I have to fiddle with. I'm installing the .cbplugin into the setup that built it so maybe that's why it works for me, although that's exactly what fails on Linux. I'm going to try building the latest on Linux today and see if it'll get through the update process, just for kicks. In the meantime, I guess you should stick with building it from source.

The other issue I have is that C::B fails when I run the plug-in in debug mode. No idea why and no information provided by the IDE. I might play around with that and see if I can trace what's failing on Linux. It might shed some light on the problem.

BTW, did you check the application log as mentioned in the error? Please post the contents.

Cheers.
Title: Re: Doxygen plugin
Post by: codeur on March 17, 2010, 08:53:34 pm
It's committed now. That should fix the toolbar issue.

It does  fix the toolbar issue, but not the menu which is still active when CB starts.

BTW, did you check the application log as mentioned in the error? Please post the contents.

Cheers.

The only log I find is a codeblocks.RPT file in the CB base directory that gets created when CB dies. It tell me for example that CB dies when doxyblock.dll attempts to access a null pointer (for example opening doxyblocks preferences and clicking OK when no project is open).  That file has no information about plugins not loading and does not get generated when a plugin fails to start.

I'll keep my eyes open and tell you if I find a clue why I cannot load your plugin if I don't re-build it.
Title: Re: Doxygen plugin
Post by: oBFusCATed on March 17, 2010, 10:47:43 pm
codeur: start C::B with "codeblocks.exe --debug-log" this option adds another log pane
Title: Re: Doxygen plugin
Post by: Cryogen on March 18, 2010, 03:46:30 am
It does  fix the toolbar issue, but not the menu which is still active when CB starts.

Oh yeah, I forgot that too. Ergh. I've fixed it now, thanks.

I'll keep my eyes open and tell you if I find a clue why I cannot load your plugin if I don't re-build it.

Thanks. I spent a few more hours wrestling with Linux and achieved nothing more than trashing my installation. Again! Nothing works. I tried to get it to build with the contrib plug-ins by integrating it into the makefiles, and it looked like it was doing so, but the result was no files in "devel". If I build it with C::B and try and run it in the same IDE in the same directory tree it locks up during startup at "Initialising plugins". If I remove DoxyBlocks (or a bunch of others I tried) it still does that so it seems not to be me. In the same environment the .cbplugin also refuses to work. I'm currently rebuilding C::B from SVN to try and get it working again. It shouldn't be this hard and I'm sure there's something fundamentally wrong with C::B's plug-in system, viz. Jens' comment elsewhere re: paths being lost. Frankly, I'm jack of fighting it on Linux and won't be doing any more until someone who understands what's required in detail decides to try and build it or it's integrated properly with the contrib plug-ins. I think Jens is the Linux man so we'll just have to wait for him to have the time, I guess.  :evil:

On the Windows front I still can't debug the thing as gdb dies. I can, however, debug contrib plug-ins from the contrib workspace so I think we're back to waiting for integration for that to work, too. I may try adding it myself and see if it wants to play ball but, for obvious reasons, I'm not optimistic.

Cheers.
Title: Re: Doxygen plugin
Post by: Cryogen on March 18, 2010, 04:27:13 am

  Hi,

Released version 1.1.123 of DoxyBlocks
-Added: I forgot to disable the menu if there are no projects open at startup. That's now done.

Special delivery for Codeur.  :wink:

Cheers.

Title: Re: Doxygen plugin
Post by: codeur on March 18, 2010, 07:30:59 am
codeur: start C::B with "codeblocks.exe --debug-log" this option adds another log pane

Thanks for the tip oBFusCATed. The message I get in the debug log when DoxyBlocks fails loading is...   failed :shock: :? :lol:
I am confident this info will solve all of Gary's issues.

Another one for you Gary. I built 1.1.123, removed the old plugin, installed the new one. No luck.
Steps to see the issue:
1- Install doxyblocks from .cbplugin (with an open project). DoxyBlocks menu and toolbar come up enabled.
2- Close all projects. DoxyBlocks menu and toolbar are disabled (greyed out).
3- Close CB, Open CB. The toolbar is disabled, the menu is enabled.

My advice: take the rest of the week and the week-end off. Spring is coming (if you are in the Northern hemisphere), take your girl out for a great bushwalk and come back refreshed. The blasted code can wait.
Title: Re: Doxygen plugin
Post by: Jenna on March 18, 2010, 06:19:02 pm
I think Jens is the Linux man so we'll just have to wait for him to have the time, I guess.  :evil:

My advice: take the rest of the week and the week-end off. Spring is coming (if you are in the Northern hemisphere), take your girl out for a great bushwalk and come back refreshed. The blasted code can wait.

I'm at work until friday (most likely late) evening, until 9 or 10 pm each day (I have internet just since half an hour here after fighting the whole week with german telecom and some ignorant builder who cut our phone cable multiple times).

I hope I will find the time to look into it at the weekend.
But it worked for me without problems (automake and build by C::B).
If you build with automake-system, devel directory is not used.
Title: Re: Doxygen plugin
Post by: Cryogen on March 18, 2010, 08:58:54 pm

 Hi Guys,

Released version 1.2.138 of DoxyBlocks
-Fixed: The menu activation code was still not right. I think I now have the right combination of events to make things happen correctly.

Hurrah!  :o

Title: Re: Doxygen plugin
Post by: Cryogen on March 18, 2010, 09:18:05 pm

Hey Codeur,

 Firstly, thanks for making the effort to test it. We need more users/developers like you!  :P

codeur: start C::B with "codeblocks.exe --debug-log" this option adds another log pane

Thanks for the tip oBFusCATed. The message I get in the debug log when DoxyBlocks fails loading is...   failed :shock: :? :lol:
I am confident this info will solve all of Gary's issues.

Awesoooooooooooome. :wink:

Another one for you Gary. I built 1.1.123, removed the old plugin, installed the new one. No luck.
Steps to see the issue:
1- Install doxyblocks from .cbplugin (with an open project). DoxyBlocks menu and toolbar come up enabled.
2- Close all projects. DoxyBlocks menu and toolbar are disabled (greyed out).
3- Close CB, Open CB. The toolbar is disabled, the menu is enabled.

:cry:
The problem here is that the MENUBAR_CREATE_END event appears to be raised before the plug-in menus are processed. I'm not sure that that's right i.e. as it should be. PLUGIN_ATTACHED occurs far too early, before the menu is even drawn. I have therefore resorted to UPDATE_UI, which seems to be doing the job. I see that many of the other plug-ins use it, so maybe it's a common necessity. This time, I've tested it much more thoroughly and run it through all of the combinations of opening and closing projects, editors and the IDE that I can come up with and it is behaving correctly so far, including independently enabling and disabling the comment functions.

My advice: take the rest of the week and the week-end off. Spring is coming (if you are in the Northern hemisphere), take your girl out for a great bushwalk and come back refreshed. The blasted code can wait.

Haha, good advice but it seems that I didn't listen. Perhaps on the weekend.  :)

Fingers crossed.


Title: Re: Doxygen plugin
Post by: codeur on March 18, 2010, 09:57:08 pm
Hurrah!  :o
Menu activation is working now (including the internal activation/deactivation of the comment functions), thanks.
Title: Re: Doxygen plugin
Post by: Cryogen on March 18, 2010, 09:57:46 pm

  Hi Jens,

I'm at work until friday (most likely late) evening, until 9 or 10 pm each day (I have internet just since half an hour here after fighting the whole week with german telecom and some ignorant builder who cut our phone cable multiple times).

Haha, everyone has their own struggle.  :?

I hope I will find the time to look into it at the weekend.
But it worked for me without problems (automake and build by C::B).

That would be great. Thanks. I have recovered C::B on Ubuntu so I now have the latest SVN running. I can still build my plug-in but all attempts to install it have failed. I also tried to integrate it into the automake build stream but that didn't work either. I don't know enough about it to see how it's done in C::B, generally.

The first thing I need to understand is why the the .cbplugin doesn't work, even in Windows where it works for me. The second is how to integrate it into the automake process. If I can build it along with the other contrib plugins it may work then. I guess the best thing would be to know what steps you take to get it working and just follow them.

If you build with automake-system, devel directory is not used.

Ahah. That would explain a few things.

Cheers.

Title: Re: Doxygen plugin
Post by: Cryogen on March 19, 2010, 09:44:41 pm

 Hi Guys,

Released version 1.2.204 of DoxyBlocks
-Added: The ability to create separate output directories for projects that live in the same directory.
-Added: Missing warning when trying to run HTML Help and it's not found.


With the addition of the separate directory functionality, I have reached the end of my current To-Do list. I'm still open to changes and additions and have been thinking about things such as being able to display man docs in the internal viewer and the option to display additional icons on the toolbar to view doc types. I still need to sort out what's going on with .cbplugins and on Linux in general and there are bound to be bug reports as people start to use it more but, for now, the bulk of the work is done.

Enjoy.
Title: Re: Doxygen plugin
Post by: codeur on March 20, 2010, 12:16:42 am
A great milestone!
BTW: With my builds the version of doxyblocks shown by the plugins manager has been 0.3.286 for as long as I remember. Why would that be?
Title: Re: Doxygen plugin
Post by: Cryogen on March 20, 2010, 03:25:17 am
 Hey,

A great milestone!
BTW: With my builds the version of doxyblocks shown by the plugins manager has been 0.3.286 for as long as I remember. Why would that be?

I would say that it's because manifest.xml is not being updated. That's where that version string comes from. Try deleting it and updating it from SVN.

Cheers,

  G.

[EDIT] BTW, if you check Help/Plugins/DoxyBlocks after the update you'll find that your name has been immortalised in code since 1.2.213. :-)


Title: Re: Doxygen plugin
Post by: codeur on March 20, 2010, 03:36:11 am
That's what I thought, but the current manifest.xml says:   <Value version="1.2.209" />
version.h is also correct with version "1.2.209.5894"
... strange.
Title: Re: Doxygen plugin
Post by: Cryogen on March 20, 2010, 04:28:57 am
That's what I thought, but the current manifest.xml says:   <Value version="1.2.209" />
version.h is also correct with version "1.2.209.5894"
... strange.

No, it says:

        <Value version="1.2.213" />

as of a few minutes ago. Try updating now.  :D

Cheers.

Title: Re: Doxygen plugin
Post by: codeur on March 20, 2010, 07:22:46 am
... I thought you were going out with your girl this week-end..?

Since you are doing some cleanups, the history on the mainpage of DoxyBlocks docs at the bottom of the doxyblocks.h header needs updating.
Title: Re: Doxygen plugin
Post by: Jenna on March 20, 2010, 12:05:45 pm
I think Jens is the Linux man so we'll just have to wait for him to have the time, I guess.  :evil:

My advice: take the rest of the week and the week-end off. Spring is coming (if you are in the Northern hemisphere), take your girl out for a great bushwalk and come back refreshed. The blasted code can wait.

I'm at work until friday (most likely late) evening, until 9 or 10 pm each day (I have internet just since half an hour here after fighting the whole week with german telecom and some ignorant builder who cut our phone cable multiple times).

I hope I will find the time to look into it at the weekend.
But it worked for me without problems (automake and build by C::B).
If you build with automake-system, devel directory is not used.

Back at home, I created two patches, one against C::B's trunk and one against DoxyBlocks trunk.
I have doxyblocks sources in "src/plugins/contrib/doxyblocks".
You can use the patches with "patch -p0 < [patch-file]" from the source-directories (the one from C::B's sources, the other from "src/plugins/contrib/doxyblocks".

It should work with automake and from inside C::B.
A .cbplugin-file is not created, because it's usability highly depends on the distros library versions and might or might not work.

By the way, you should remove the .depend and .layout files from svn and make sure, that the linux/unix specific files do not get dos line-endings (especially the update-script) and the update-script has to be executable.

Ah, and I fixed a bug, that can lead to a crash if no editor is opened in "DoxyBlocks.cpp"

[attachment deleted by admin]
Title: Re: Doxygen plugin
Post by: Cryogen on March 20, 2010, 08:20:00 pm
... I thought you were going out with your girl this week-end..?

Since you are doing some cleanups, the history on the mainpage of DoxyBlocks docs at the bottom of the doxyblocks.h header needs updating.

Yes, well, we hadn't reached the weekend here, yet, and it's snowing now, so waddyagonnado? :-)

Thanks, it should be OK now with the next SVN.

Title: Re: Doxygen plugin
Post by: Cryogen on March 20, 2010, 08:27:20 pm

  Hi Guys,

Released version 1.2.218 of DoxyBlocks
-Fixed: Nasty bug that caused C::B to crash if no editors were open when DoxyBlocks functions were used.

I stumbled across the solution to the problem, last night, thankfully. Morten, please remove it from the questions list, I have to eat humble pie on this one.

Thanks.

Title: Re: Doxygen plugin
Post by: Cryogen on March 20, 2010, 08:47:29 pm

  Hi Jens,

Back at home, I created two patches, one against C::B's trunk and one against DoxyBlocks trunk.

Thanks. I have done much of that on Linux but, since it fails, haven't incorporated it into SVN. I'll tinker with these later today.

By the way, you should remove the .depend and .layout files from svn and make sure, that the linux/unix specific files do not get dos line-endings (especially the update-script) and the update-script has to be executable.

Roger that.

Ah, and I fixed a bug, that can lead to a crash if no editor is opened in "DoxyBlocks.cpp"

Yeah, me too but I think I like your solution better as it makes fewer calls. Thanks. Much appreciated.


Title: Re: Doxygen plugin
Post by: Cryogen on March 21, 2010, 04:39:38 am
 Hi Jens/Guys,

Released version 1.2.221 of DoxyBlocks
-Fixed: Finally got it to run on Linux with Jens' help by integrating with contrib plug-ins and building from there.
-Updated: Changed my fix from 1.2.218 to Jens' version as it's more efficient.


At long last I've finally seen it running on Linux.  :mrgreen:

That's a really nice step forward, thanks for your efforts.

With that and the bug fix we're looking really good.



  Hi Jens,

Back at home, I created two patches, one against C::B's trunk and one against DoxyBlocks trunk.

Thanks. I have done much of that on Linux but, since it fails, haven't incorporated it into SVN. I'll tinker with these later today.

My system still had some issues but I finally got it running. It looks like you created your own directory and used lower case. For consistency with the package and my setup, I have changed the couple of instances where your patch used "doxyblocks" to "DoxyBlocks". If you could do the same that would be appreciated. There are:

configure.in (3)
src/ContribPlugins-unix.workspace (1)
src/plugins/contrib/Makefile.am (1)
acinclude.m4 (1)

Attached is a copy of your patch with those changes made. Hopefully that will save you having to mess around.

Thanks again,

  Gary.




[attachment deleted by admin]
Title: Re: Doxygen plugin - paths to documentation tools
Post by: codeur on March 22, 2010, 01:01:28 am
This request is to make doxyblocks usable in portable versions of Code::Blocks.

In order to make DoxyBlocks portable, could the paths to the documentation executables in the general preferences screen be made to use Codeblocks variables? The paths to the tools could then be made relative to the CB installation.

As an example being able to enter something like $(CODEBLOCKS)\tool\Graphviz\bin\dot.exe
rather than E:\Program Files\codeblocks\tool\Graphviz\bin\dot.exe as the path would make doxyblocks usable in a portable CB installation.
Thanks.
Title: Re: Doxygen plugin - paths to documentation tools
Post by: MortenMacFly on March 22, 2010, 07:00:40 am
As an example being able to enter something like $(CODEBLOCKS)\tool\Graphviz\bin\dot.exe
@Cryogen: True, you can achieve that easily using a call to macros manager before applying the path's. It's a one-liner per path.

BTW: Really, really: Nice work! I've just upgraded from 0.4 to the SVN... well done!
Title: Re: Doxygen plugin
Post by: Jenna on March 22, 2010, 07:13:22 am
My system still had some issues but I finally got it running. It looks like you created your own directory and used lower case. For consistency with the package and my setup, I have changed the couple of instances where your patch used "doxyblocks" to "DoxyBlocks". If you could do the same that would be appreciated. There are:

I also had the DoxyBlocks-plugin in a CamelCase-named suubdirectory and only changed it to lower-case, because your svn-directory is in lower-case too.
The contrib-plugins not all use CamelCase (even if I prefer it as you can see at my "own" plugin IncrementalSearch).

In short: it's no problem to me (debian files have to be fixed accordingly, if debian build-scripts are used, of course).
Title: Re: Doxygen plugin
Post by: ptDev on March 22, 2010, 12:06:43 pm
Before anything else, thank you very much for making Doxygen so much easier to use! :D

I have a small feature request: is it possible to add the doxygen flags EXTRACT_PRIVATE and EXTRACT_STATIC explicitly to the "Doxygen Defaults" tab? Although I never check EXTRACT_ALL, the setting is overriden by them, and I would like to have control over the documentation of private class members.

Of course, I can easily edit the generated doxygen settings file to this end, but it would make a big difference for me if I could have it generated the way I need it from the get-go.
Title: Re: Doxygen plugin
Post by: Cryogen on March 22, 2010, 08:56:21 pm

 Hi Guys,

Released version 1.2.223 of DoxyBlocks
-Fixed: Bug in the config. panel that caused the OUTPUT_DIRECTORY label to be obscured on Linux.


This is just a small bug-fix release.

Cheers.
Title: Re: Doxygen plugin - paths to documentation tools
Post by: Cryogen on March 22, 2010, 08:59:50 pm

 Hey dude,

This request is to make doxyblocks usable in portable versions of Code::Blocks.

That's a very good idea, yes.

In order to make DoxyBlocks portable, could the paths to the documentation executables in the general preferences screen be made to use Codeblocks variables? The paths to the tools could then be made relative to the CB installation.

As an example being able to enter something like $(CODEBLOCKS)\tool\Graphviz\bin\dot.exe
rather than E:\Program Files\codeblocks\tool\Graphviz\bin\dot.exe as the path would make doxyblocks usable in a portable CB installation.
Thanks.

I was wondering whether it wasn't simpler just to add the required paths to the system path, which is catered for already, however see my response to Morten's follow-up.

Thanks.
Title: Re: Doxygen plugin - paths to documentation tools
Post by: Cryogen on March 22, 2010, 09:06:11 pm

 Hi Morten,

As an example being able to enter something like $(CODEBLOCKS)\tool\Graphviz\bin\dot.exe
@Cryogen: True, you can achieve that easily using a call to macros manager before applying the path's. It's a one-liner per path.

OK, cool. I will look at this because I like to build in as much flexibility as possible and, in general, it seems like a good idea.
I guess that having to add to system paths could be a bit of a nuisance and having another option is definitely a "good thing".  :)

BTW: Really, really: Nice work! I've just upgraded from 0.4 to the SVN... well done!

Thanks. I always try to do good work but it's always very nice to hear that someone appreciates it. I'm glad you approve.  :P

Cheers,

  Gary.

Title: Re: Doxygen plugin
Post by: Cryogen on March 22, 2010, 09:11:59 pm
  Hey Jens,

I also had the DoxyBlocks-plugin in a CamelCase-named suubdirectory and only changed it to lower-case, because your svn-directory is in lower-case too.
The contrib-plugins not all use CamelCase (even if I prefer it as you can see at my "own" plugin IncrementalSearch).

OK, I think I see how that happened. the SourceForge unix name for the project is "doxyblocks" even though the project name is "DoxyBlocks". I used lower case reflexively when I set it up and it can't be subsequently changed. I can see how that could cause confusion. However, the directory you check out into is named by the user so we just have to educate users until it becomes part of contrib, I think.

In short: it's no problem to me (debian files have to be fixed accordingly, if debian build-scripts are used, of course).

OK, ta. Did I miss those? I'll check.

[EDIT:] No, I didn't. They're in the patch, I just neglected to list them below. ;-)

Cheers.
Title: Re: Doxygen plugin
Post by: Cryogen on March 22, 2010, 09:25:27 pm

  Hi ptDev,

Before anything else, thank you very much for making Doxygen so much easier to use! :D

Thanks for the feedback, you're welcome.  :D

I have a small feature request: is it possible to add the doxygen flags EXTRACT_PRIVATE and EXTRACT_STATIC explicitly to the "Doxygen Defaults" tab? Although I never check EXTRACT_ALL, the setting is overriden by them, and I would like to have control over the documentation of private class members.

Of course, I can easily edit the generated doxygen settings file to this end, but it would make a big difference for me if I could have it generated the way I need it from the get-go.

Certainly, yes. It'll give me something to do today. I'll report back when it's in SVN.

Cheers.
Title: Re: Doxygen plugin
Post by: Cryogen on March 22, 2010, 09:59:02 pm
 Some notes for Windows users.

Jens' patch doesn't update the Windows workspace for contrib plug-ins. To do so you need to do a few things:

1. Add DoxyBlocks' project to the contrib plugins workspace manually.

Now, because my installation doesn't match what C::B expects and config doesn't build the wx library with the name it expects (anyone care to advise me on this?)...

2. Open DoxyBlocks' build settings, select the "default" build and then the "Linker settings" tab and change the first entry under "Link libraries:" from "wx_msw$(WX_SUFFIX)-2.8.dll" to "wxmsw28$(WX_SUFFIX)".

If you have used a different wx library pattern on your system, replace mine with that.

3. Open the "Search directories" tab and on the "Compiler" sub-tab change "$(#wx.lib)\wx\include\msw-unicode-release-2.8" to "$(#WX.lib)\gcc_dll$(WX_CFG)".

Again, if your wx build directory tree is different, use the correct pattern for your installation.

Finally, for consistency with the other projects...

4. Open the "Pre/post build steps" tab and remove the line that starts "zip -j9 DoxyBlocks.cbplugin ..." from the "Post-build steps" window, unless you want the .cbplugin to be built, and check the checkbox at the bottom entitled "Always execute, even if target is up-to-date".

You should now be able to build DoxyBlocks with the other contrib plug-ins in a consistent way.

Cheers,

 Gary.

[EDIT:] Do this, too, so that you can debug the plug-in from the contrib workspace:

5. In the "Project" menu select "Set program's arguments" whilst DoxyBlocks' project is active. In the resulting dialogue enter "--debug-log -na -ns -nd" under "Program's arguments" and "..\..\..\devel\codeblocks.exe" under "Host application".

Title: Re: Doxygen plugin - paths to documentation tools
Post by: codeur on March 22, 2010, 10:27:49 pm
Hi Morten,
. . .
OK, cool. I will look at this because I like to build in as much flexibility as possible and, in general, it seems like a good idea.
I guess that having to add to system paths could be a bit of a nuisance and having another option is definitely a "good thing".  :)
. . .

Thanks for this Gary.
I don't think adding to the CB-internal system path instead would really be a nuisance, but, since they are there already, your 4 or 5 paths to the executables are a useful reminder to nubies of the tool requirements of doxygen.
Title: Re: Doxygen plugin
Post by: Cryogen on March 23, 2010, 06:01:05 am
  Hi Guys,

Released version 1.3.236 of DoxyBlocks
-Added: Configuration of EXTRACT_PRIVATE and EXTRACT_STATIC. Requested by ptDev.
-Updated: Changed the generated doxyfile to doxygen 1.6.3.
-Updated: For consistency, changed HTML_TIMESTAMP default to YES.
-Updated: For consistency, changed EXTRACT_LOCAL_METHODS default to NO.
-Added: Macro expansion in path prefs so that you can use things like "$(CODEBLOCKS)" in paths. Requested by Codeur.


I have added the features requested by ptDev and Codeur. Let me know how they go for you, guys. They worked well here.

I have also updated the generated doxyfile to version 1.6.3. I checked through the current default values set by Doxygen and changed those mentioned to match doxygen's defaults. The timestamp is useful and local methods are only useful for Objective C users. DoxyBlocks inherited settings from jomeggs' script, which was not configurable and therefore set some default values that were thought to be widely used. Most of those are configurable in DoxyBlocks. The remaining settings that are not set to doxygen's defaults and not configurable in DoxyBlocks are:

SettingPurposeValue
FULL_PATH_NAMESPrepend the full path before files name in the file listNO
GENERATE_TREEVIEWGenerate index tree view in side panelYES
CALL_GRAPHHave dot generate a call dependency graphYES

The purest way to do things would be to provide configuration for any setting that is not set to doxygen's default. I think that those three settings are pretty fair as they are but some folks might prefer other settings. Should these be set to doxygen's defaults and accessible via doxywizard? Should these, or other settings, be added to DoxyBlocks configuration panel? Does anyone have any thoughts on this?

Cheers.
Title: Re: Doxygen plugin
Post by: LordCB on March 23, 2010, 09:35:34 am
I can´t still install ya plugin
and in sourceforge i see only version 1.2.209

could anybody illuminate me
Title: Re: Doxygen plugin
Post by: codeur on March 23, 2010, 10:49:31 am
...
Released version 1.3.236 of DoxyBlocks

I have added the features requested by ptDev and Codeur. Let me know how they go for you, guys. They worked well here.

After a quick check, the executable paths using CB variables in "preferences" work well for me too. Many thanks.
I can place a portable CB based on BN 6190 onto a USB HDD and get DoxyBlocks to work immediately on any XP SP3 computer around (I cannot test on other systems).

I can´t still install ya plugin
and in sourceforge i see only version 1.2.209

could anybody illuminate me

Gary is currently trying to get a CB install that will allow him to produce .cbplugin (s)  that work for all of us. He is making good progress, but until he succeeds we build DoxyBlocks from subversion with modified projects on our own systems in order to test working plugins on our systems (the possibility of having the doxygen plugin on the next release is what motivates us to test it in these conditions despite the inconvenience). The SVN on SourceForge is at version 1.3.236.
Title: Re: Doxygen plugin
Post by: ptDev on March 23, 2010, 11:35:34 am
  Hi Guys,

Released version 1.3.236 of DoxyBlocks
-Added: Configuration of EXTRACT_PRIVATE and EXTRACT_STATIC. Requested by ptDev.
(...)
I have added the features requested by ptDev and Codeur. Let me know how they go for you, guys. They worked well here.

Working fine here, too. Right now, your plugin is PERFECT for me. Thank you very much! :D
Title: Re: Doxygen plugin
Post by: Cryogen on March 23, 2010, 06:36:59 pm

  Hi there,

I can´t still install ya plugin
and in sourceforge i see only version 1.2.209

could anybody illuminate me

Yes. Give up on .cbplugins, they're not going to work. You need to follow the instructions here and build it from source.

Let there be light.  :idea: :D
Title: Re: Doxygen plugin
Post by: Cryogen on March 23, 2010, 06:45:42 pm

 Greetings,

After a quick check, the executable paths using CB variables in "preferences" work well for me too. Many thanks.
I can place a portable CB based on BN 6190 onto a USB HDD and get DoxyBlocks to work immediately on any XP SP3 computer around (I cannot test on other systems).

Working fine here, too. Right now, your plugin is PERFECT for me. Thank you very much! :D

That' s great, guys, thanks. Aaah, the joys of open source.  :P

Gary is currently trying to get a CB install that will allow him to produce .cbplugin (s)  that work for all of us. He is making good progress, but until he succeeds we build DoxyBlocks from subversion with modified projects on our own systems in order to test working plugins on our systems (the possibility of having the doxygen plugin on the next release is what motivates us to test it in these conditions despite the inconvenience). The SVN on SourceForge is at version 1.3.236.

Actually, I'm not. I'm of the opinion it's not worth the effort and, as Jens pointed out, too dependent on library versions and other factors. In other words, nice idea but it's broke. However, if you were to build it yourself in your C::B installation, the .cbplugin it generates might work for you. If not, you're back to building it with C::B.

Cheers.
Title: Re: Doxygen plugin - producing a .cbplugin installer
Post by: codeur on March 23, 2010, 07:50:33 pm
Actually, I'm not. I'm of the opinion it's not worth the effort and, as Jens pointed out, too dependent on library versions and other factors. In other words, nice idea but it's broke. However, if you were to build it yourself in your C::B installation, the .cbplugin it generates might work for you. If not, you're back to building it with C::B.

I feel that there could be some confusion here between the concept of publishing an ideal .cbplugin that could work on any past and future builds of Code::Blocks (that obviously cannot work), and the concept of publishing source code and a project file producing a .cbplugin that would work on an official release and could be maintained for nightlies. One such official release is in preparation at this time. I may be mistaken, but I think LordCB is currently testing for that purpose.

However I am out of my depth here and will let the maintainers speak to us on that.
Title: Re: Doxygen plugin - producing a .cbplugin installer
Post by: Cryogen on March 23, 2010, 09:47:00 pm

 Hey Codeur,

I feel that there could be some confusion here between the concept of publishing an ideal .cbplugin that could work on any past and future builds of Code::Blocks (that obviously cannot work), and the concept of publishing source code and a project file producing a .cbplugin that would work on an official release and could be maintained for nightlies. One such official release is in preparation at this time. I may be mistaken, but I think LordCB is currently testing for that purpose.

However I am out of my depth here and will let the maintainers speak to us on that.

Mmm, LordCB isn't a maintainer, I think he's just trying to install the plug-in. Creating a .cbplugin from the release code might work but that would be redundant, wouldn't it, as it would be in the contrib plug-ins (I hope)?  :wink:

Ciao.


Title: Re: Doxygen plugin - producing a .cbplugin installer
Post by: MortenMacFly on March 24, 2010, 04:25:31 pm
Creating a .cbplugin from the release code might work but that would be redundant, wouldn't it, as it would be in the contrib plug-ins (I hope)?  :wink:
Notice that a *.cbplugin for Linux would surely depend on the libraries / system you use. However, this concept works reliable under Windows and should work reliable at least for (some) major Linux distros.
Title: Re: Doxygen plugin - producing a .cbplugin installer
Post by: Cryogen on March 24, 2010, 06:28:21 pm
Notice that a *.cbplugin for Linux would surely depend on the libraries / system you use. However, this concept works reliable under Windows and should work reliable at least for (some) major Linux distros.

As far as I am aware no-one has been able to install the Windows .cbplugins I've been making available. I'll put the latest on SourceForge. Please let me know if it works for you.

Thanks.
Title: Re: Doxygen plugin - producing a .cbplugin installer
Post by: skunky79 on March 25, 2010, 03:06:00 pm
Notice that a *.cbplugin for Linux would surely depend on the libraries / system you use. However, this concept works reliable under Windows and should work reliable at least for (some) major Linux distros.

As far as I am aware no-one has been able to install the Windows .cbplugins I've been making available. I'll put the latest on SourceForge. Please let me know if it works for you.

Thanks.


Not working for me! (C::B 8.02 on WinXP)
Title: Re: Doxygen plugin - producing a .cbplugin installer
Post by: Aelxx on March 25, 2010, 08:06:30 pm
Notice that a *.cbplugin for Linux would surely depend on the libraries / system you use. However, this concept works reliable under Windows and should work reliable at least for (some) major Linux distros.

As far as I am aware no-one has been able to install the Windows .cbplugins I've been making available. I'll put the latest on SourceForge. Please let me know if it works for you.

Thanks.
Not working on my PC with C::B build 6181 on WinXP.
Title: Re: Doxygen plugin - producing a .cbplugin installer
Post by: Cryogen on March 26, 2010, 01:47:11 am

Not working for me! (C::B 8.02 on WinXP)

Not working on my PC with C::B build 6181 on WinXP.

Thanks, guys. We're not expecting it to work in 8.02 but its' interesting that it fails in the SVN build as that's very recent.

Cheers.
Title: Re: Doxygen plugin - producing a .cbplugin installer
Post by: codeur on March 26, 2010, 04:43:22 am

Not working for me! (C::B 8.02 on WinXP)

Not working on my PC with C::B build 6181 on WinXP.

Thanks, guys. We're not expecting it to work in 8.02 but its' interesting that it fails in the SVN build as that's very recent.

Cheers.

Title: Re: Doxygen plugin - producing a .cbplugin installer
Post by: codeur on March 26, 2010, 04:54:48 am

Thanks, guys. We're not expecting it to work in 8.02 but its' interesting that it fails in the SVN build as that's very recent.


Hi Gary,
As you probably know already, your .cbplugin does not work on SVN 3190 either. It is built on your own non standard CB installation with a non-standard project and is likely to work only on your installation.
I guess that if you do not provide a standard working project based on a standard installation and capable of producing a .cbplugin that works on standard systems one of the maintainers will.
The issue then will be that the published  project will not be compatible with your own development system. It'll make it more work for you to maintain it.
Title: Re: Doxygen plugin
Post by: oBFusCATed on March 26, 2010, 10:15:15 am
Uf, why do you bother with the cbplugin, after the release I'm sure the DoxyBlocks will be integrated in the contrib plugins and all will have it.  :lol:
Title: Re: Doxygen plugin
Post by: MortenMacFly on March 26, 2010, 08:36:52 pm
after the release I'm sure the DoxyBlocks will be integrated in the contrib plugins and all will have it.  :lol:
I support that, too. So it'll be with some others I have in mind, too...
Title: Re: Doxygen plugin
Post by: Cryogen on March 26, 2010, 11:00:54 pm
after the release I'm sure the DoxyBlocks will be integrated in the contrib plugins and all will have it.  :lol:
I support that, too. So it'll be with some others I have in mind, too...

Nice, thanks.  :o
Title: Re: Doxygen plugin - producing a .cbplugin installer
Post by: Cryogen on March 27, 2010, 07:24:54 am
Hi Gary,
As you probably know already, your .cbplugin does not work on SVN 3190 either. It is built on your own non standard CB installation with a non-standard project and is likely to work only on your installation.
I guess that if you do not provide a standard working project based on a standard installation and capable of producing a .cbplugin that works on standard systems one of the maintainers will.
The issue then will be that the published  project will not be compatible with your own development system. It'll make it more work for you to maintain it.

Yes, well, the problem with that is trying to find the way to create a "standard" installation. My requests for assistance have been ignored, so far. However, I did manage to stumble across the solution last night. I then spent several more frustrating hours rebuilding wx numerous times, trying to find out why that fails, rebuilding C::B, finding that that wouldn't run, installing 8.02 so that I could rebuild the damned thing and recovering the situation, which required manually placing files that the build didn't put in place.  :cry:

However, it's working now and I finally have a setup that uses the standard build paths and doesn't require me to modify the project files to make it run. Here's hoping that the .cbplugin, which I'm about to release, works finally. Either way, things should now be easier for all of us.  :D

It will also mean that the project will now streamline itself with the contrib workspace properly. That has to be a good thing.

Ciao.


Title: Re: Doxygen plugin
Post by: Cryogen on March 27, 2010, 07:26:39 am

  Hi Guys,

Released version 1.3.289 of DoxyBlocks
-Fixed: I have changed my setup and the project to run with the paths expected by C::B. Hopefully this will solve the failures to run experienced by .cbplugin users and bring it into line with other contrib projects.

Hurrah!  :lol:

Title: Re: Doxygen plugin
Post by: codeur on March 27, 2010, 12:21:37 pm
Wow! This time DoxyBlocks builds off the shelf on CB build 6190. There is no need anymore for me to merge my version of the project with yours as had been the case with previous releases.

Gary, your published .cbplugin still does not load on my system. I am not surprised, but the difference this time probably comes from my side as I have newer versions of the compiler and libraries. The .cbplugin produced by your un-modified project on my system loads without a hitch.

Apologies for pushing you so insistently. I thought I might have gone too far this time. At least now that you have done it, you have a standard system that will allow you to maintain your plugin more easily in the future.

I am very grateful to you for having provided such a convenient access to doxygen. A portable Code::Blocks (a recent build) including DoxyBlocks will be installed and used by our many users here (I hope) in the next few weeks. It will then really be tested for good. I am likely to have some feedback for you then.
Title: Re: Doxygen plugin
Post by: Cryogen on March 27, 2010, 11:00:16 pm

 Hi again,

Wow! This time DoxyBlocks builds off the shelf on CB build 6190. There is no need anymore for me to merge my version of the project with yours as had been the case with previous releases.

That's the idea. :-)

[/quote]
Gary, your published .cbplugin still does not load on my system. I am not surprised, but the difference this time probably comes from my side as I have newer versions of the compiler and libraries. The .cbplugin produced by your un-modified project on my system loads without a hitch.

OK, ta. I'm keen to see if it works for anyone else, now. Not that it's critical but it would be nice to know that the current setup produces workable code.

Apologies for pushing you so insistently. I thought I might have gone too far this time. At least now that you have done it, you have a standard system that will allow you to maintain your plugin more easily in the future.

Not necessary, thanks. No, there's never been a lack of intention, just a lack of information, but I get there eventually in most cases, anyway. ;-)

I am very grateful to you for having provided such a convenient access to doxygen. A portable Code::Blocks (a recent build) including DoxyBlocks will be installed and used by our many users here (I hope) in the next few weeks. It will then really be tested for good. I am likely to have some feedback for you then.

No problems. I'm increasingly pleased with it and glad to see it being well received. Have fun.

Cheers.

Title: Re: Doxygen plugin
Post by: Cryogen on March 27, 2010, 11:09:20 pm

 Hi Guys,

Released version 1.3.312 of DoxyBlocks
-Fixed: Bug that prevented the output directory being created if a sub-directory was used and didn't already exist.
-Fixed: Bug in prefs loading code that prevented global prefs from being loaded for a project which hadn't previously used DoxyBlocks.
-Updated: The generated doxyfile couldn't be run directly by doxygen due to the way that relative paths were created. Changed how DoxyBlocks creates and runs the doxyfile so that it can be run directly by other agents.


I found a couple of bugs that I hadn't detected before. The third item above was a nasty gotcha. You have to expect that doxygen will be able to run the doxyfile natively, so that was well caught. Re: the second item, these are the prefs that are global, and should load for all projects (assuming they've been set at least once):
-The 5 paths;
-overwrite doxyfile;
-prompt before overwriting;
-Use internal viewer;
-Run HTML;
-Run CHM;

I considered these things to be generic to how you use doxygen, rather than related to a specific project.

Cheers,

  Gary.

Title: Re: Doxygen plugin
Post by: Cryogen on March 28, 2010, 07:30:51 am

 I must be bored...  :o

Released version 1.4.366 of DoxyBlocks
-Added: Information about macro expansion to the config. panel path tooltips.
-Cleaned: Removed the .cbplugin creation command from both Windows and Unix projects.
-Added: You can now click the URL displayed in the log window to view the HTML docs.
-Updated: Changed the config Get functions to be constant.


You can now click the link in the log window to run the HTML docs. Nice if you have changed projects, or just for convenience. The link is only written to the log when you run view the HTML using the internal viewer but, once it's available, DoxyBlocks will respect your settings and open the docs in the internal viewer or your browser.
The .cbplugin command in the project files is now gone so it should match the other contrib projects exactly.

Cheers.
Title: Re: Doxygen plugin
Post by: maofde on March 28, 2010, 03:13:00 pm
Hi guys,

sorry for my noob question, but I already struggle in the compiling step:


Using Ubuntu 9.10 with C::B 8.02 or SVN 6196, I chose the DoxyBlocks-unix.cbp project and simply pushed the build-button.
The I get errror messages:


Code
Can't create object output directory /home/.objs/plugins/contrib/DoxyBlocks/
Can't create output directory /home/devel/share/codeblocks/plugins/

Do I have to place the doxyblocks source into a special folder? Or what else I'm doing wrong?

Thanks for your support in advance.
Title: Re: Doxygen plugin
Post by: Cryogen on March 28, 2010, 07:20:14 pm
 Hi there,

Hi guys,

sorry for my noob question, but I already struggle in the compiling step:


Using Ubuntu 9.10 with C::B 8.02 or SVN 6196, I chose the DoxyBlocks-unix.cbp project and simply pushed the build-button.
The I get errror messages:


Code
Can't create object output directory /home/.objs/plugins/contrib/DoxyBlocks/
Can't create output directory /home/devel/share/codeblocks/plugins/

Do I have to place the doxyblocks source into a special folder? Or what else I'm doing wrong?

Thanks for your support in advance.

The best bet is to put it in the CodeBlocks source directory structure in src/plugins/contrib/. That will allow it to put the files it builds into the right directories along with the other plugins. Build it, then run the update script and you should have DoxyBlocks in your release version.

If you go one step further and add DoxyBlocks' project to the contrib plugins workspace provided with CodeBlocks source, you can build it along with the others in one fell swoop.

Oh, and it won't work with 8.02. Use the SVN version.

Have fun.
Title: Re: Doxygen plugin
Post by: MortenMacFly on March 29, 2010, 07:16:19 am
Released version 1.4.366 of DoxyBlocks
BTW: You should add a virtual target named "All" to your project files that would compile the main target. This would ensure that when compiling the C::B workspace (where all projects / target belong also to the virtual target "all") you plugin gets compiled, too. I just realised that. Have a look at other plugins if in doubt.
Title: Re: Doxygen plugin
Post by: codeur on March 29, 2010, 07:45:19 am
As I start using DoxyBlocks in a few projects myself prior to the big release, I am going to dribble in a few issues as I encounter them. Starting now:

The "default commenting style preferences" is a major one:
In a work place (or an educational institution) that has several programmers, they all use the same style standards that usually define their commenting style and other aspects. In those places, they will always use the same preferences for all projects. These include not only the global preferences that you have listed a few days ago, but many other aspects, like using @ in tags, or selecting the QT style for block comments or the C++ slash style of line comments, etc...

For those people, it would be a pain if they had to set their preferences according to their in-house standards again every time they start a new project. Could ALL the commenting style preferences last used be stored and become the new default commenting style preferences when a new, not yet commented project is started?

And a minor one:
The prototype: int yes( const char *question );
generates: ----- * @param *question constchar ----- for the parameter.
The prototype: bool yes( const string &question );
generates: -----  * @param &question conststring ----- for the parameter.
Can this be easily fixed?

Thanks.
Title: Re: Doxygen plugin
Post by: MortenMacFly on March 29, 2010, 08:06:24 am
For those people, it would be a pain if they had to set their preferences according to their in-house standards again every time they start a new project. Could ALL the commenting style preferences last used be stored and become the new default commenting style preferences when a new, not yet commented project is started?
I was thinking about that myself. My idea would be to have a template file which is read on startup rather than hard-coded internally. This file you could load and parse the buffer for certain tokens to replace - similar as we do it with the default code or C::B's HTML startup page, for example.
So something like this:
Code
PROJECT_NAME           = Code::Blocks
would become:
Code
PROJECT_NAME           = $(project_name)

This is very flexible as you could use macro replacements in addition for updating flags. Besides you can easily upgrade any flags needed in the UI (for easier access) by just another macro (replacement) in the template file. Users familiar with environment variables could make use of this, too without needing to compile the plugin. Just edit the template,. setup an envvar and you are done. :-) Surely the settings applied using DoxyBlocks directly should always supersede.
Furthermore an update of doxygens default config file would be as simple as updating this single file... etc... I hope you get my point.
Title: Re: Doxygen plugin
Post by: Cryogen on March 29, 2010, 07:46:40 pm

  Hi Guys,

For those people, it would be a pain if they had to set their preferences according to their in-house standards again every time they start a new project. Could ALL the commenting style preferences last used be stored and become the new default commenting style preferences when a new, not yet commented project is started?
I was thinking about that myself. My idea would be to have a template file which is read on startup rather than hard-coded internally. This file you could load and parse the buffer for certain tokens to replace - similar as we do it with the default code or C::B's HTML startup page, for example.


Interesting point. I can see that it would be useful to be able to apply a default configuration set, yes. The idea of being able to use macros in the default config also sounds good. I'll look at it.

Thanks,

  Gary.

Title: Re: Doxygen plugin
Post by: Cryogen on March 29, 2010, 07:49:35 pm

 Hey Codeur,

As I start using DoxyBlocks in a few projects myself prior to the big release, I am going to dribble in a few issues as I encounter them. Starting now:
And a minor one:
The prototype: int yes( const char *question );
generates: ----- * @param *question constchar ----- for the parameter.
The prototype: bool yes( const string &question );
generates: -----  * @param &question conststring ----- for the parameter.
Can this be easily fixed?

Fixed? Yes. Easily? No. ;-)

It will require further tinkering with the regexes, at which I'm no expert, but I will see what I can come up with. It should parse multiple args correctly.

Thanks.
Title: Re: Doxygen plugin
Post by: Cryogen on March 29, 2010, 08:12:24 pm
Released version 1.4.366 of DoxyBlocks
BTW: You should add a virtual target named "All" to your project files that would compile the main target. This would ensure that when compiling the C::B workspace (where all projects / target belong also to the virtual target "all") you plugin gets compiled, too. I just realised that. Have a look at other plugins if in doubt.

Yup, missed that. Done, thanks.
Title: Re: Doxygen plugin
Post by: Cryogen on April 01, 2010, 09:13:07 pm

  Hi Guys,

Released version 1.5.440 of DoxyBlocks
-Added: Virtual target "All", for consistency.
-Updated: Menu text so that only the first word is capitalised, as per the existing convention.
-Added: New functionality to save and load a configuration template. Requested by Codeur.

Codeur, have a play with this. It saves the file, DoxyBlocks.ini, in C::B's global config directory, which should be C:\Users\<USER>\AppData\Roaming\codeblocks on Windows.

Cheers.
Title: Re: Doxygen plugin
Post by: stahta01 on April 01, 2010, 10:39:16 pm
Contented Delete to improve tone of there.
Title: Re: Doxygen plugin
Post by: Cryogen on April 02, 2010, 06:35:32 pm

 Hi,

should be C:\Users\<USER>\AppData\Roaming\codeblocks on Windows.

Prefered %APPDATA%\codeblocks folder.

If you could manage a complete sentence, that would help. ;-)

What does this mean? Are you suggesting that it would be better to use the path you mention? If so, I can only say that that directory doesn't exist and I don't propose to create a non-standard path. Otherwise, please explain. Note that things may yet change somewhat with this functionality, as well.

Thanks.
Title: Re: Doxygen plugin
Post by: stahta01 on April 02, 2010, 07:03:55 pm
Contented Delete to improve tone of there.
Title: Re: Doxygen plugin
Post by: ptDev on April 02, 2010, 07:46:16 pm

 Hi,

should be C:\Users\<USER>\AppData\Roaming\codeblocks on Windows.

Prefered %APPDATA%\codeblocks folder.

If you could manage a complete sentence, that would help. ;-)

What does this mean? Are you suggesting that it would be better to use the path you mention? If so, I can only say that that directory doesn't exist and I don't propose to create a non-standard path. Otherwise, please explain. Note that things may yet change somewhat with this functionality, as well.

Thanks.


%APPDATA% is a standard path. Just like %TEMP% is the windows standard for the temporary directory, and %USERPROFILE% the user home directory. Try entering any of these environment variables in the start menu and see what happens.
Title: Re: Doxygen plugin
Post by: Cryogen on April 02, 2010, 10:53:41 pm

  Tim,


I gave the correct location of the Code::Blocks folder NOT just the Windows 7 location.

While I see, now, what you intended and appreciate the intention to help, I don't appreciate the tone. If you'd care to contribute and explain yourself more clearly, please do, otherwise direct your efforts elsewhere.

If you are a Linux person; I excuse your remark; but, a windows programmer should know better.

Tim S.

Well, gee thanks. Of course, you assume that the path I mentioned here in an effort to assist another is the one that's coded in the extension. Well, we all know what happens when one assumes, don't we?

Title: Re: Doxygen plugin
Post by: Cryogen on April 02, 2010, 10:55:07 pm

 Hi again,

%APPDATA% is a standard path. Just like %TEMP% is the windows standard for the temporary directory, and %USERPROFILE% the user home directory. Try entering any of these environment variables in the start menu and see what happens.

Yes, thanks, I do know that. ;-)

Cheers.
Title: Re: Doxygen plugin
Post by: stahta01 on April 03, 2010, 12:20:08 am
Contented Delete to improve tone of there.
Title: Re: Doxygen plugin
Post by: codeur on April 03, 2010, 12:47:51 am
Tim, Gary, please stop that squabble... it does not matter who started first.
It makes both of you feel miserable and makes both of you look like the "letter of the alphabet" you have started calling each-other.
Let's get back to business.
Title: Re: Doxygen plugin
Post by: Cryogen on April 03, 2010, 12:59:17 am

 Hi Guys,

Released version 1.5.454 of DoxyBlocks
-Updated: Function args including const should now be parsed correctly.
Title: Re: Doxygen plugin
Post by: Cryogen on April 03, 2010, 01:02:23 am
Tim, Gary, please stop that squabble... it does not matter who started first.
It makes both of you feel miserable and makes both of you look like the "letter of the alphabet" you have started calling each-other.
Let's get back to business.

Yes, I agree. Unfortunately I didn't realise that such childish behaviour was likely to occur here. Shame.

Ciao.
Title: Re: Doxygen plugin
Post by: Cryogen on April 03, 2010, 01:06:08 am
You are an A because you are not able to think and read; my tone was not bad till after yours was a.

Edit: I am very sorry for assuming your were a programmer.

Tim S.


Deary me. If you refer to my first response, that was a perfectly civil request for an explanation. If you failed to detect that I'm afraid it's you who has the reading disability.
Shall we just move on now, then?

Title: Re: Doxygen plugin
Post by: codeur on April 03, 2010, 01:11:18 am
Gary, here is your explanation:
The reason why using the %APPDATA% environment variable is preferable is that this location is often redirected (the environment variable reassigned) when launching Code::Blocks in a portable manner.

For example I use a CB launcher that reassigns %APPDATA% with:     SetEnvironmentVariable(_T("APPDATA"), currDir);
before executing codebocks.exe

edit: I know that Biplab does the same in his CBlauncher and loaden also does something similar, except that he modified the CB code to do it.
Title: Re: Doxygen plugin
Post by: codeur on April 03, 2010, 01:28:12 am
Thanks for the fix for arguments with const modifiers. I'll soon give a good shake up to variations of argument types and return values and report to you.

Regarding the "settings template", it basically works, but I do not understand the purpose of the "Load settings template" entry.
Isn't the settings template if it exists supposed to be loaded automatically on startup?
Unless you are planning on adding the possibility of choosing between multiple templates in the future (which would be great!), I do not see the use of "Load settings".
Title: Re: Doxygen plugin
Post by: codeur on April 03, 2010, 06:26:33 am
Testing the function banner comment generation:
The const parameter issue is fixed. Thanks.
A few other issues would really benefit if they are fixed before a release (like the first one and perhaps the second). Others we can live with for a while.

/** @brief Example 1: Return type issue
 *
 * @param param1 const int*
 * @param param2 const string&
 * @return string
 *
 */    
string &myFunc(const int * param1, const string &param2);

The parameters are now perfect! The return type should show it is a reference.
(Same problem when the return type is a pointer).

-----------------------------------------------------------
/** @brief Example 2: C-style string array (**) issue
 *
 * @param *param1 char*
 * @return char
 *
 */    
char *myFunc(char **param1)

The name contains one of the *. The return type illustrates the return type issue with pointers.

-----------------------------------------------------------
** @brief Example 3: array notation
 *
 * @param param1[] char*
 * @return char
 *
 */    
char *myFunc(char *param1[])

I imagine this would be specially hard to fix (and the output is understandable anyway).

-----------------------------------------------------------
/** @brief example 4: Operator not recognised as function
 *
 * @param
 * @param
 * @return
 *
 */    
Rational Rational::operator + (const Rational &other) const;

This would be an acceptable solution when the syntax is too complex for the parser.

-----------------------------------------------------------
/** @brief example 5: inline (and static) taken as return types
 *
 * @param num int
 * @param den int
 * @return inline
 *
 */    
inline Rational::Rational(int num, int den) : numerator(num), denominator(den){}

inline and static function modifiers are taken as return types.
Title: Re: Doxygen plugin
Post by: Cryogen on April 03, 2010, 07:29:59 pm

  Hey there,

Gary, here is your explanation:
The reason why using the %APPDATA% environment variable is preferable is that this location is often redirected (the environment variable reassigned) when launching Code::Blocks in a portable manner.

For example I use a CB launcher that reassigns %APPDATA% with:     SetEnvironmentVariable(_T("APPDATA"), currDir);
before executing codebocks.exe

edit: I know that Biplab does the same in his CBlauncher and loaden also does something similar, except that he modified the CB code to do it.

OK, thanks. Didn't know any of that. Currently, I'm just using the sdk function to return the default prefs directory, as per some other plug-ins. Since I knew you'd come back asking for the ability to load files from elsewhere, I expected to add to it. Can you provide an example of a plug-in that does this, off hand?

Cheers.
Title: Re: Doxygen plugin
Post by: Cryogen on April 03, 2010, 07:51:50 pm

Regarding the "settings template", it basically works, but I do not understand the purpose of the "Load settings template" entry.

It's very straightforward. You save a template from a project that has the settings you want. When you are in a project that you want to import those settings into, you load them.
Remember it's a fairly superficial first draught. :-)

Isn't the settings template if it exists supposed to be loaded automatically on startup?
Unless you are planning on adding the possibility of choosing between multiple templates in the future (which would be great!), I do not see the use of "Load settings".

No, that won't happen. There are default settings loaded when you first open prefs. After that, the prefs saved in the project are loaded. What the template functionality will do is allow you to import a set of prefs to avoid having to set them manually, as you initially mentioned. Once they're imported, they're saved in the project and loaded from there on subsequent occasions. The only real question is where we're loading the template from. It sounds like the best option would be to have a file selection dialogue that defaults to the directory pointed to by %APPDATA%. You would then get the default location initially, wherever that might be in the circumstances, and can browse from there. How does that sound?


Title: Re: Doxygen plugin
Post by: Cryogen on April 03, 2010, 07:59:47 pm

Testing the function banner comment generation:
The const parameter issue is fixed. Thanks.
A few other issues would really benefit if they are fixed before a release (like the first one and perhaps the second). Others we can live with for a while.

I have to deal with these one at a time as you find them, so leave them with me.

Thanks.
Title: Re: Doxygen plugin
Post by: codeur on April 04, 2010, 01:55:29 am
There are default settings loaded when you first open prefs. After that, the prefs saved in the project are loaded. What the template functionality will do is allow you to import a set of prefs to avoid having to set them manually, as you initially mentioned. Once they're imported, they're saved in the project and loaded from there on subsequent occasions.

This needs to be thought out carefully. At the moment 3 different sets of prefs can be active at various points:
1 - The default prefs (active when no previously used project has been opened and no settings template loaded). All settings involved.
2 - The user prefs (active when the user has loaded a settings template or edited the defaults). All editable settings involved.
3 - A project prefs (active when the user has loaded a previously saved project). All except global settings involved.

Based on the current structure, this is how I imagine most users will expect the preferences to work in various cases:

** Case 1 - I have just installed CB, or just activated DoxyBlocks, no template has ever been saved:
- New project:
When I start a new project the default prefs (1) are active. They offer the most common choices and will work OK on most systems.
- Existing project:
When I load an existing project, the project DoxyBlocks settings (3) become active, overriding all except global settings.

** Case 2 - I have used DoxyBlocks for a while and saved my preferences into a template:
- New project:
When I start a new project the user prefs (2) from the template are active. They are my choices and I don't want to have to manually load them at each new project.
- Existing project:
When I load an existing project, the project DoxyBlocks settings (3) become active, overriding all except global settings.
With the "Load settings" option I can override the project settings with the template settings if I want.

** In all cases:
I can edit the preferences and save them to the user prefs template at any time. All current preferences except global preferences are saved to the project.

-------------------------------
In light of this:

- Load settings issue:
Note that in the above scenarios I have indeed found a usage for the "Load settings" option in Case 2, Existing project (if we keep the current structure with project prefs - see below.).

- No loading of user prefs on startup:
You seem to have a different scenario in mind for Case 2, new project, one that would force a user to manually load their chosen settings from template every time a new project is started.
Are you sure requiring this repetitive manual loading is needed? Is the automatic loading of user preferences on startup hard to do?

- Getting rid of project prefs:
Is the saving of DoxyBlocks project prefs in projects and loading of these preferences from projects really useful? What would be the cost of simply getting rid of project prefs? If the costs are not great, being able to simplify the prefs this way could be worth doing.

-------------------
For Later:
When we have discussed this, we will have to examine what happens when a new project is started after an existing one, or when several projects are concurrently in memory. These are issues that disappear if we get rid of project prefs.
Title: Re: Doxygen plugin
Post by: codeur on April 04, 2010, 02:10:02 am
The only real question is where we're loading the template from. It sounds like the best option would be to have a file selection dialogue that defaults to the directory pointed to by %APPDATA%. You would then get the default location initially, wherever that might be in the circumstances, and can browse from there. How does that sound?

Offering saving directory choice is an added interface complexity. It would also make the automatic loading of user preferences that I am plugging for in my previous post impossible.
How about just saving into %APPDATA% or a preset subdirectory of %APPDATA% without giving the choice?
Title: Re: Doxygen plugin
Post by: Cryogen on April 06, 2010, 10:36:08 pm
 Hi Codeur,

This needs to be thought out carefully. At the moment 3 different sets of prefs can be active at various points:

You have obviously been thinking far too much about this. ;-)

Firstly, the whole %APPDATA% discussion has been smoke and mirrors. I am using the sdk function which, as expected, happily returns the correct value of that variable, wherever it may be pointing. I have done a lot of research and tested with biplab's script and the cbLauncher. The current code correctly returns the redirected directory in each case. Therefore, the current code should be doing what you want with the exception of automatically loading your template by default when you create a new project.

BTW, I presume this is you:

<secret URL>  :mrgreen:

If so, it's good to see how it's being used.

When I start a new project the user prefs (2) from the template are active. They are my choices and I don't want to have to manually load them at each new project.

Perhaps I underestimated the laziness of the average developer. :-)
I think the difference is probably that, in your educational scenario, you are probably in a position where you create small projects often, whereas I, and I suspect most users, would be much more likely to create new projects fairly rarely and spend most of our time revisiting existing projects. However, I'm all for automation and convenience so I don't see it as a bad thing. The question then becomes how best to implement it in the current framework.

In light of this:

- Load settings issue:
Note that in the above scenarios I have indeed found a usage for the "Load settings" option in Case 2, Existing project (if we keep the current structure with project prefs - see below.).

Goodo.

- No loading of user prefs on startup:
You seem to have a different scenario in mind for Case 2, new project, one that would force a user to manually load their chosen settings from template every time a new project is started.
Are you sure requiring this repetitive manual loading is needed? Is the automatic loading of user preferences on startup hard to do?

Yes, that was the idea. No, but possibly. Possibly not, I haven't looked at the details yet. Perhaps what we need is a way for the user to have their template prefs used as the default prefs? That's basically what you're seeking. Sounds reasonable.

- Getting rid of project prefs:
Is the saving of DoxyBlocks project prefs in projects and loading of these preferences from projects really useful? What would be the cost of simply getting rid of project prefs? If the costs are not great, being able to simplify the prefs this way could be worth doing.

-------------------
For Later:
When we have discussed this, we will have to examine what happens when a new project is started after an existing one, or when several projects are concurrently in memory. These are issues that disappear if we get rid of project prefs.

You bet it's useful. The cost would be having to stick them elsewhere, which really gains nothing that I can see and loses a bunch of built-in functionality, or not having per-project prefs, which would render the whole thing far less useful and would be a very large step backwards.
It's very unlikely that I will be getting rid of project prefs. The only reason I don't say "won't" is because I prefer not to deal in absolutes. Things change. However, don't start holding your breath as I'd hate to see you expire.  :lol:

I'm also extremely disinclined to unwind/undo/reverse weeks of work.

I think that what you're after can be provided by reworking how "default" prefs are managed. I'll look into that.

You've probably also noticed that I've slowed down the work rate a fair bit in the last week or so. That's probably going to continue so the releases will be a bit slower.

Cheers.


Title: Re: Doxygen plugin
Post by: Cryogen on April 06, 2010, 10:38:53 pm
The only real question is where we're loading the template from. It sounds like the best option would be to have a file selection dialogue that defaults to the directory pointed to by %APPDATA%. You would then get the default location initially, wherever that might be in the circumstances, and can browse from there. How does that sound?

Offering saving directory choice is an added interface complexity. It would also make the automatic loading of user preferences that I am plugging for in my previous post impossible.
How about just saving into %APPDATA% or a preset subdirectory of %APPDATA% without giving the choice?

I was only referring to loading. I still think we're going to need to consider whether someone wants to load a template from elsewhere but I'll stick with the one location for now while we sort that out.

Cheers.
Title: Re: Doxygen plugin
Post by: codeur on April 07, 2010, 01:01:00 am
Thanks for replying to my long email.
I am not surprised that you are slowing development on this. It felt like you were working full time on DoxyBlocks previously, and while I was rejoicing at the great job you have done so far, I am also glad for you that you are stepping back and taking a rest from it. There's life beyond them thar mountains of code.

Yes, I am the guilty party putting together CB EDU-Portable.
Can you please edit that post of yours and obfuscate the EDU-Portable URL for search engines as it was on the original post in Biplab's blog (like replacing the dots by "dot" and removing http://). I'll move that page around if needed to frustrate the search engines if they already recorded the URL.
This thing is a kind of development version only tested in-house (an Australian university) for now. The web page is not ready for public access (no source published, too many bugs). In addition codecutter does not support the traffic necessary to deliver the large downloads that this package would generate if it became advertised on some "freeware" sites.
A new release of EDU-Portable is on its way where things start really working (and DoxyBlocks will be there). I'll tell you where and when it is available.

Regarding %APPDATA%, you are indeed doing the correct thing by calling the SDK function (that function behaves strangely and all ini files end up in the application root directory instead of the %APPDATA% directory after %APPDATA% is changed, but this is not an issue with DoxyBlocks. I have to investigate).

Regarding offering loading the template from elsewhere, it is not an issue with me if it is loading only, it's only an extra click to ignore it, we can live with this. I was afraid that you would be offering saving elsewhere as well.

Using the saved template for the default preferences of Doxyblocks would indeed do what is needed to fix the default user prefs.

I was not really expecting you to accept getting rid of the per-project preferences (for the reasons you mention).
On my side I see much added complexity there and some potential issues but little benefit (especially after you fix the default prefs). At some later stage you'll have to do a cost-benefit analysis of that. It is preferable if that happens before the new Code::Blocks release, changing major design issues like this if that is your final decision would become difficult afterwards. We'll live with per-project prefs for now.

Once again many thanks for this work. Getting apprentice programmers to start documenting their code is tough (ask any programming teacher). With DoxyBlocks presented up-front on the CodeBlocks menu, it will become easy. Students will see it as a normal thing to do and almost as a game. DoxyBlocks will be a major asset for CB EDU-Portable.

Title: Re: Doxygen plugin
Post by: Cryogen on April 07, 2010, 08:58:42 pm

 Hey Codeur,

Thanks for replying to my long email.

Not at all, old chap.  8)

I am not surprised that you are slowing development on this. It felt like you were working full time on DoxyBlocks previously, and while I was rejoicing at the great job you have done so far, I am also glad for you that you are stepping back and taking a rest from it. There's life beyond them thar mountains of code.

That's because I was. Yes, you're right. ;-)

Yes, I am the guilty party putting together CB EDU-Portable.

Nice one.

Can you please edit that post of yours and obfuscate the EDU-Portable URL... (whole bunch of good reasons)

Sure thing. Done.

A new release of EDU-Portable is on its way where things start really working (and DoxyBlocks will be there). I'll tell you where and when it is available.

Even better.  :D

Regarding offering loading the template from elsewhere, it is not an issue with me if it is loading only, it's only an extra click to ignore it, we can live with this. I was afraid that you would be offering saving elsewhere as well.

That's probably reasonable on the basis that someone wanting to load a template from outside the default config directory is not likely to want to have to dig through the horrendous Windows user directory structure to find it when it's saved, before they can take it elsewhere. It would be a separate option from saving to the default location, though. We'll see.

I was not really expecting you to accept getting rid of the per-project preferences (for the reasons you mention).
On my side I see much added complexity there and some potential issues but little benefit ...

Hmmm, I dunno why and I don't agree. To me, the template is purely a way of importing a set of prefs, nothing more. It can in no way replace the existing system for storing and managing prefs. There are already measures in place to manage switching between projects, etc. That's WHY we have per-project prefs. ;-)

Once again many thanks for this work. Getting apprentice programmers to start documenting their code is tough (ask any programming teacher). With DoxyBlocks presented up-front on the CodeBlocks menu, it will become easy. Students will see it as a normal thing to do and almost as a game. DoxyBlocks will be a major asset for CB EDU-Portable.

You're welcome, and thanks. More power to you for teaching things the right way.

Title: Re: Doxygen plugin
Post by: codeur on April 07, 2010, 10:13:33 pm

 
I was not really expecting you to accept getting rid of the per-project preferences (for the reasons you mention).
On my side I see much added complexity there and some potential issues but little benefit ...

Hmmm, I dunno why and I don't agree. To me, the template is purely a way of importing a set of prefs, nothing more. It can in no way replace the existing system for storing and managing prefs. There are already measures in place to manage switching between projects, etc. That's WHY we have per-project prefs. ;-)


I know that I will not make you change your mind on per-project prefs and I accept this since you have been working with the per-project prefs paradigm for a long time.
Don't conclude that I think this is a really major affair because I talk about it again. It is not really that important, but you say that you don't know why, so I'll try to make you understand.

Just one common scenario where per-project prefs would be a nuisance:
Prior to teaching I was a "software engineer" (read "programmer"). As in all good software development places we had in-house style standards. These included documenting (there was no such thing as doxygen then, although we had tried CCDOC). There were periodic revisions of the standards (every couple of years on average) and we had to write new code according to the current standards and bring old code, when it was maintained, up to the current standards. That's the way things are done in many places.

With prefs in DoxyBlocks automatically based on the current template, and no per-project prefs, all this editing of comments to current in-house standards and generation of documentation according to current practice would be automatic. The way it is set now (with per-project prefs and no automatic setting of default prefs from template) we could still do the same thing simply by clicking on "Load Settings" every time we would decide to edit a project, old or new. Of course some programmers would sometimes forget and we would have documentation of maintained projects sometimes with the older and sometimes with current versions of the standards.

Now I can also see that outside that standard work environment, someone who may be sub-contracting to various companies and who could be working with different groups of people with different standards would prefer the per-project approach.

But the heck with those work places. For now, in practice, if you simply automatically set the DoxyBlocks default prefs from template if it exists and keep per-project prefs, that'll be sufficient in my educational environment.
Title: Re: Doxygen plugin
Post by: caoselee on April 13, 2010, 09:03:34 am
In My Humble Opinion, we don't need DoxyBlocks at all. first, it can't work in my CodeBlocks; second, we can just use Doxys with CodeBlocks's Tools option. :?
Title: Re: Doxygen plugin
Post by: Cryogen on April 21, 2010, 07:39:34 pm

  Hi,

In My Humble Opinion, we don't need DoxyBlocks at all. first, it can't work in my CodeBlocks; second, we can just use Doxys with CodeBlocks's Tools option. :?

You can certainly use doxygen from the Tools menu. I suspect we've all done that. However, DoxyBlocks does much more than just run doxywizard, as you'd know if you'd read through here. If you prefer to enter comment blocks manually or use macros or some other means, then you probably won't need DoxyBlocks. If not, you still might find it useful.

Cheers.
Title: Re: Doxygen plugin
Post by: Cryogen on April 21, 2010, 08:02:31 pm

 Hi Guys,

Released version 1.5.502 of DoxyBlocks
-Added: Functionality to better process the function return string and the keywords "static" and "inline".
-Added: Functionality to process ** in parameters and return values.

Codeur, I've run it on all of your examples and variations of them and it seems to be doing well. A couple of Qs:

-----------------------------------------------------------
** @brief Example 3: array notation
 *
 * @param param1[] char*
 * @return char
 *
 */    
char *myFunc(char *param1[])

Currently, your example causes DoxyBlocks to generate this:

Code
/** \brief Brief desc.
 *
 * \param param1[] char*
 * \return char*
 *
 */
char *myFunc(char *param1[]){};

and doxygen generates:

char* DoxyBlocks::myFunc  ( char *  param1[]  )  [inline, private]

Brief desc.

Parameters: param1[]  char*

Returns: char*

which seems OK to me. Doxygen accepts it without parsing errors, which is a major factor, too. What did you have in mind?

-----------------------------------------------------------
/** @brief example 4: Operator not recognised as function
 *
 * @param
 * @param
 * @return
 *
 */    
Rational Rational::operator + (const Rational &other) const;

This is a matter of style. The regexes can't account for all of the variations and preferences of users and, even if they could, I don't have the skills to make them do so. If you remove the spaces, this works as expected:

Code
Rational Rational::operator+(const Rational &other) const;

If you choose to retain the spaces you are given the standard, empty comment block, rather than nothing. This seems reasonable.

-----------------------------------------------------------
/** @brief example 5: inline (and static) taken as return types
 *
 * @param num int
 * @param den int
 * @return inline
 *
 */   
inline Rational::Rational(int num, int den) : numerator(num), denominator(den){}

I don't understand this declaration as my understanding, which you'll no doubt correct where necessary, is that inline functions must be declared in the header where the namespace name is illegal or unnecessary.  :?:
However, the point is a good one. It now handles the "static" and "inline" keywords.

Thanks for the detailed report.

Gary.
Title: Re: Doxygen plugin
Post by: codeur on April 24, 2010, 03:56:48 am
Thanks for the latest edit.
Yes, those last changes work and the function banner comment generation becomes quite usable.

The style with spaces around the operator is very common. It's pity it cannot be easily fixed. We'll live with it.
You are right, the namespace in a header would not be legal, but thanks for the job with inline, static and **

It's all looking good.

Sorry to raise this again:
The last thing that remains bothering me is the loading of settings from template not being done automatically when there is no project or even when one creates a new project.
That initial loading does not conflict with settings being loaded from project when an existing project is started, which I understand you are determined to keep.
I don't think that initial loading of settings from template when no existing project is loaded goes against your preferred design. It would be a nice improvement for all users (of course more important for those who start new projects frequently as is the case for my own set of users). It does not seem to be a priority for you.
Is it a major modification?
Title: Re: Doxygen plugin
Post by: maofde on May 02, 2010, 09:26:31 am
Hi,

I've still trouble getting doxyblocks to work under linux.
Could anybody please give me a receipe on how to compile doxyblocks and link everything together?

Here is what I've done so far:

I got C::B-svn 6193 and applied jens "DoxyBlocks-AutoMake-CB-20100320-1.patch" patch as describe earlier in this thread.
Then I got doxyblocks-svn 32 and placed it here: trunk/src/plugins/contrib/DoxyBlocks. I figured out, that the second patch is included already.
Then I ran ./bootstrap, ./configure --prefix=/opt/codeblocks-svn --with-contrib-plugins=all, ./make, sudo ./make install  <--- no error messages until here.

Then I start codeblocks directly in /opt/bin/codeblocks and receive the following message:

Quote
...
Scanning for plugins in /opt/codeblocks-svn/lib/codeblocks/plugins
/opt/codeblocks-svn/lib/codeblocks/plugins/libDoxyBlocks.so: not loaded (missing symbols?)
Loaded 38 plugins
...

Additionally in the lower left a small yellow box appears an says
Quote
One or more plugins were not loaded. This usually happens when a plugin is built for a different version of the Code::Blocks SDK. Check the application log for more info. List of failed plugins: libDoxyBlocks.so

ldd /opt/codeblocks-svn/lib/codeblocks/plugins/libDoxyBlocks.so shows this:
Quote
linux-vdso.so.1 =>  (0x00007fff715ff000)
libcodeblocks.so.0 => /opt/codeblocks-svn/lib/libcodeblocks.so.0 (0x00007f1800f9e000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f1800d5f000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f1800b5a000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f180084a000)
libm.so.6 => /lib/libm.so.6 (0x00007f18005c6000)
libc.so.6 => /lib/libc.so.6 (0x00007f1800256000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f180003f000)
libwx_gtk2u_richtext-2.8.so.0 => /usr/lib/libwx_gtk2u_richtext-2.8.so.0 (0x00007f17ffd47000)
libwx_gtk2u_aui-2.8.so.0 => /usr/lib/libwx_gtk2u_aui-2.8.so.0 (0x00007f17fface000)
libwx_gtk2u_xrc-2.8.so.0 => /usr/lib/libwx_gtk2u_xrc-2.8.so.0 (0x00007f17ff834000)
libwx_gtk2u_qa-2.8.so.0 => /usr/lib/libwx_gtk2u_qa-2.8.so.0 (0x00007f17ff611000)
libwx_gtk2u_html-2.8.so.0 => /usr/lib/libwx_gtk2u_html-2.8.so.0 (0x00007f17ff35f000)
libwx_gtk2u_adv-2.8.so.0 => /usr/lib/libwx_gtk2u_adv-2.8.so.0 (0x00007f17ff07c000)
libwx_gtk2u_core-2.8.so.0 => /usr/lib/libwx_gtk2u_core-2.8.so.0 (0x00007f17fea62000)
libwx_baseu_xml-2.8.so.0 => /usr/lib/libwx_baseu_xml-2.8.so.0 (0x00007f17fe856000)
libwx_baseu_net-2.8.so.0 => /usr/lib/libwx_baseu_net-2.8.so.0 (0x00007f17fe626000)
libwx_baseu-2.8.so.0 => /usr/lib/libwx_baseu-2.8.so.0 (0x00007f17fe2cf000)
/lib64/ld-linux-x86-64.so.2 (0x00007f18018b2000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00007f17fdcc3000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00007f17fda17000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00007f17fd7f7000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00007f17fd5cd000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00007f17fd3b1000)
libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x00007f17fd107000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00007f17fcebd000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007f17fcc38000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007f17fca06000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007f17fc7be000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f17fc5ba000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007f17fc3b5000)
librt.so.1 => /lib/librt.so.1 (0x00007f17fc1ac000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00007f17fbee5000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007f17fbce3000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x00007f17fbad9000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00007f17fb8b3000)
libz.so.1 => /lib/libz.so.1 (0x00007f17fb69c000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00007f17fb476000)
libtiff.so.4 => /usr/lib/libtiff.so.4 (0x00007f17fb21b000)
libexpat.so.1 => /lib/libexpat.so.1 (0x00007f17faff1000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00007f17fade4000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f17faaae000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x00007f17fa8ab000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007f17fa6a8000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007f17fa4a2000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007f17fa21f000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f17fa00c000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f17f9e02000)
libXi.so.6 => /usr/lib/libXi.so.6 (0x00007f17f9bf7000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007f17f99ed000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00007f17f97e3000)
libpcre.so.3 => /lib/libpcre.so.3 (0x00007f17f95b4000)
libresolv.so.2 => /lib/libresolv.so.2 (0x00007f17f939b000)
libselinux.so.1 => /lib/libselinux.so.1 (0x00007f17f917d000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x00007f17f8f61000)
libuuid.so.1 => /lib/libuuid.so.1 (0x00007f17f8d5c000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f17f8b3f000)
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x00007f17f88fa000)
libdirectfb-1.2.so.0 => /usr/lib/libdirectfb-1.2.so.0 (0x00007f17f866f000)
libfusion-1.2.so.0 => /usr/lib/libfusion-1.2.so.0 (0x00007f17f8464000)
libdirect-1.2.so.0 => /usr/lib/libdirect-1.2.so.0 (0x00007f17f8249000)
libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0x00007f17f8045000)
libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x00007f17f7e3b000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f17f7c38000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f17f7a32000)

Everything seems to be fine  :?

So, what am I doing wrong?
Thanks for your effort.

Btw: I tested doxyblocks under windows already (there without problems during svn-compilation) and I really want to have it now on linux to work with it everyday.
Title: Re: Doxygen plugin
Post by: Jenna on May 02, 2010, 11:37:10 am
Hi,

I've still trouble getting doxyblocks to work under linux.
Could anybody please give me a receipe on how to compile doxyblocks and link everything together?

Add DoxyBlocksLogger.* to the project-file, they seem to miss in the linux-version.

Title: Re: Doxygen plugin
Post by: maofde on May 03, 2010, 08:13:43 pm
Add DoxyBlocksLogger.* to the project-file, hey seem to miss in the linux-version.

You are right, I added this to the doxygen-project, but it still don't work here:-(
Title: Re: Doxygen plugin
Post by: Cryogen on May 16, 2010, 05:14:38 am

 Hi,

Add DoxyBlocksLogger.* to the project-file, hey seem to miss in the linux-version.

You are right, I added this to the doxygen-project, but it still don't work here:-(

I'm looking into this for you.

Cryo.
Title: Re: Doxygen plugin
Post by: Phenom on May 16, 2010, 08:03:55 pm
Hi,

I downloaded the doxyblocks.cbplugin from sourceforge but when I install
it through the Plugin Manager I get the usual error message:
"One or more plugins where not loaded... " etc.

I'm using svn 6181 under Windows XP.
Title: Re: Doxygen plugin
Post by: Cryogen on May 17, 2010, 07:32:18 pm

 Hi Guys,

Released version 1.5.508 of DoxyBlocks
-Fixed: Fixed a crash that occurred when saving settings from the system configuration dialogue when no project was open. Reported by danselmi.
-Fixed: Template menu items not disabled with the others.

Cheers,

  Cryo.
Title: Re: Doxygen plugin
Post by: Cryogen on May 17, 2010, 07:35:49 pm

  Hi Phenom,

Hi,

I downloaded the doxyblocks.cbplugin from sourceforge but when I install
it through the Plugin Manager I get the usual error message:
"One or more plugins where not loaded... " etc.

I'm using svn 6181 under Windows XP.

Please don't bother with the .cbplugin. It's mentioned at length elsewhere here but I gave up trying to create one that works for everyone. It seems that there are just too many variables. Please use the SVN repository and build it yourself. You shouldn't have any trouble with it then.

Cheers,

  Gary.
Title: Re: Doxygen plugin
Post by: Phenom on May 17, 2010, 07:44:23 pm
Ok, thx.

Taking a look at the plugin source I saw the line:

Code
#include <wx/wx.h>

So do I need wxWidgets to compile myself?
Title: Re: Doxygen plugin
Post by: Cryogen on May 20, 2010, 01:14:58 am

  Hi,

Ok, thx.

Taking a look at the plugin source I saw the line:

Code
#include <wx/wx.h>

So do I need wxWidgets to compile myself?

Well, yes. You need a wxWidgets build environment set up. That takes a little bit of work and you will find lots of help around the forum. I suggest starting with the wiki page at http://wiki.codeblocks.org/index.php?title=Main_Page (http://wiki.codeblocks.org/index.php?title=Main_Page) that explains the setup.

Also try this:
http://wiki.codeblocks.org/index.php?title=WxWindowsQuickRef (http://wiki.codeblocks.org/index.php?title=WxWindowsQuickRef)

Cheers.

Title: Re: Doxygen plugin
Post by: Cryogen on May 20, 2010, 05:46:26 am
 Hi maofde,

Add DoxyBlocksLogger.* to the project-file, hey seem to miss in the linux-version.

You are right, I added this to the doxygen-project, but it still don't work here:-(

I have updated the unix build files. Building works for me using:

Code
make
...
sudo make install

on Ubuntu Karmic. C::B has what I think are serious issues on Linux. I can't run it from C::B, either, although I can build it. Why we have to build from the command line when we're building an IDE I don't know but it refuses to work from the IDE for me. Changes are in the latest SVN.

Cryo.
Title: Re: Doxygen plugin
Post by: Cryogen on May 20, 2010, 05:47:22 am

 Hi,

Released version 1.5.511 of DoxyBlocks
-Fixed: Unix build files.
-Removed: Debug statement that was inadvertently left behind.

Cheers.
Title: Re: Doxygen plugin
Post by: Jenna on May 20, 2010, 08:15:59 am
on Ubuntu Karmic. C::B has what I think are serious issues on Linux. I can't run it from C::B, either, although I can build it. Why we have to build from the command line when we're building an IDE I don't know but it refuses to work from the IDE for me. Changes are in the latest SVN.

Works fine here on debian.
From IDE or from commandline.

Did you run ./update after the first build to copy the xrc's and other resources ?
Title: Re: Doxygen plugin
Post by: Cryogen on May 21, 2010, 04:46:05 am

 Jens/maofde,

After rebuilding wx and C::B for unrelated reasons, Doxyblocks now works from the installed version and from my built versions, including via run.sh. I don't know exactly what changed to make the difference but it's nice either way.

Cheers.
Title: Re: Doxygen plugin
Post by: maofde on May 22, 2010, 09:23:17 pm

 Jens/maofde,

After rebuilding wx and C::B for unrelated reasons, Doxyblocks now works from the installed version and from my built versions, including via run.sh. I don't know exactly what changed to make the difference but it's nice either way.

Cheers.


I'll give it a try tomorrow with a fresh brain  8)

Edit:  svn6261 with Jens patch (adapted to the newer version), doxyblocks rev34 --> on ubuntu 9.10-x64 building via make works fine now!

 Thank you Cryogen, it works! This plugin is incredible useful.  :D
Title: Re: Doxygen plugin
Post by: Cryogen on May 23, 2010, 08:47:57 pm

 Hi,


I'll give it a try tomorrow with a fresh brain  8)

Edit:  svn6261 with Jens patch (adapted to the newer version), doxyblocks rev34 --> on ubuntu 9.10-x64 building via make works fine now!

 Thank you Cryogen, it works! This plugin is incredible useful.  :D

That's good and thanks, I'm glad you find it so.

  Gary.
Title: Re: Doxygen plugin
Post by: DanRR on June 03, 2010, 08:24:55 am
Hi,
The last Doxygen version (1.3.312) won't load with CB 10.5.
Will there be a version that supports 10.5?
Title: Re: Doxygen plugin
Post by: maofde on June 06, 2010, 06:28:04 pm
Hi Gary,

I've found an inconvenient situation when using latex formulas: If you have a syntax error inside the formula, usually latex asks what to do and waits for a user input. doxygen waits for latex to finish, which never happends, because there is no possibility to interact with latex, which in the end causes doxyblocks to block codeblocks.

I've two solutions in mind: Either it should be possible to abort the doxygen-call inside codeblocks, or it should be possible to get the console in which doxygen runs and interact there with latex.

I would prefer the second option, the first one would just avoid killing C::B each time doxygen doesn't finish.

Best,
maofde
Title: Re: Doxygen plugin
Post by: danselmi on June 07, 2010, 09:04:00 am
or just start latex with the option
Code
-interaction=nonstopmode
Title: Re: Doxygen plugin
Post by: Cryogen on June 07, 2010, 04:13:57 pm

 Hi,

Hi,
The last Doxygen version (1.3.312) won't load with CB 10.5.
Will there be a version that supports 10.5?


I'd need a lot more information than that before I can do anything for you. I use it almost every day with increasingly later SVN versions. I currently have SVN 6333. 10.5 was SVN 6283, according to the revision graph. What are you trying to do and in what way won't it load?

Cheers.
Title: Re: Doxygen plugin
Post by: stahta01 on June 07, 2010, 04:55:24 pm

 Hi,

Hi,
The last Doxygen version (1.3.312) won't load with CB 10.5.
Will there be a version that supports 10.5?


I'd need a lot more information than that before I can do anything for you. I use it almost every day with increasingly later SVN versions. I currently have SVN 6333. 10.5 was SVN 6283, according to the revision graph. What are you trying to do and in what way won't it load?

Cheers.


What type compiler are you using SJLJ or DW2 like Code::Blocks is using; the plugin failed to load for me and it is a missing symbol like error in code::blocks log.
Code
DoxyBlocks.dll: not loaded (missing symbols?)
Tim S.
Title: Re: Doxygen plugin
Post by: Cryogen on June 07, 2010, 05:32:50 pm

 Hi maofde,

I've found an inconvenient situation when using latex formulas: If you have a syntax error inside the formula, usually latex asks what to do and waits for a user input. doxygen waits for latex to finish, which never happends, because there is no possibility to interact with latex, which in the end causes doxyblocks to block codeblocks.

I've two solutions in mind: Either it should be possible to abort the doxygen-call inside codeblocks, or it should be possible to get the console in which doxygen runs and interact there with latex.

I would prefer the second option, the first one would just avoid killing C::B each time doxygen doesn't finish.

I'm sorry to hear that. Unfortunately, I have never seen or used LaTeX. I'd be happy to try and improve things for you but I'd need a lot more information in order to do that. Did danselmi's suggestion help you at all?

Another thought. DoxyBlocks just runs the doygen application. Killing that process should avoid the need to kill C::B.

Cheers,

  Gary.
Title: Re: Doxygen plugin
Post by: Cryogen on June 07, 2010, 05:48:27 pm

 Hi Tim,

What type compiler are you using SJLJ or DW2 like Code::Blocks is using; the plugin failed to load for me and it is a missing symbol like error in code::blocks log.
Code
DoxyBlocks.dll: not loaded (missing symbols?)
Tim S.

I'm sorry, I don't know what you mean.

Cheers.
Title: Re: Doxygen plugin
Post by: Cryogen on June 07, 2010, 05:59:05 pm
 Hi Guys,

It seems that the last few queries might be due to folks trying to use a DoxyBlocks.dll that they've built with the new 10.5 release.

Firstly, until now I wasn't even fully aware that there was a new release. I'd seen no announcement, I rarely visit the main page and I don't use release versions. I knew it was coming and was hoping the DoxyBlocks would be released with it but, having just downloaded the release and checked, I see that it isn't.

So, 10.5 will be no different to 8.02, I'm sure. DoxyBlocks won't work with it. You will still have to build C::B yourself from source for it to work.

Cheers.

[UPDATE]
I may be able to build a plug-in that works in 10.5 for Windows users. Unfortunately, I can't get anything other than my home-built wx libs to run under Ubuntu. If someone wants to build a plug-in using the 10.5 source and the default dev libs, I'm happy to post it on SF for all to use. The same goes for Windows for that matter. I can provide the required scripts to build the plug-in on both platforms.

Title: Re: Doxygen plugin
Post by: surrealist14 on June 24, 2010, 12:21:53 am
Hi Cryogen,

I'm no expert at this yet, but I did successfully rebuild Code::Blocks 10.05 for Windows.  I have also downloaded revision 34 of DoxyBlocks and rebuilt it from the source.  It appears to be running with my installation of C::B now, and at least I can do simple things like insert a comment block and have DoxyBlocks pluck out the parameters and return value for me!

I would be happy to share this with anyone, but I confess that I do not know how to build the .cbplugin that you mentioned.  I have a zip file with the DoxyBlocks.dll, a DoxyBlocks.zip, and some images that appear to be related.  I have a .zip file, but it's too large to attach to this post.  I'm happy to upload it somewhere more appropriate, and if all goes well, you should simply have to extract it and then copy the contents to the appropriate directory inside your Code::Blocks 10.05 Windows installation.  It seems so simple that it really should be part of the standard Code::Blocks binary distribution, IMHO.

I hope this helps, and I'm happy to try to bundle this up in a better fashion if someone can give me a little coaching.

Surrealist14
Title: Re: Doxygen plugin
Post by: killerbot on June 24, 2010, 07:09:49 am
fyi : DoxyBlocks is sitting ready on my system to become a contrib plug-in.
We are trying to iron out some last issues.

And then we will create a nightly containing it.
Other plug---ins coming at the same time are :
* Nassi-Shneiderman
* Cscope
* Aligner


Title: Re: Doxygen plugin
Post by: ollydbg on June 24, 2010, 07:25:48 am
fyi : DoxyBlocks is sitting ready on my system to become a contrib plug-in.
We are trying to iron out some last issues.

And then we will create a nightly containing it.
Other plug---ins coming at the same time are :
* Nassi-Shneiderman
* Cscope
* Aligner


Great news!
Hopefully it will be on the svn repository soon.  :D
Title: Re: Doxygen plugin
Post by: danselmi on June 24, 2010, 09:27:54 am
The Aligner plugin was merged with the EditorTweaks plugin. Do you plan to add EditorTweaks or the "old" Aligner?
Title: Re: Doxygen plugin
Post by: killerbot on June 24, 2010, 11:41:32 am
The Aligner plugin was merged with the EditorTweaks plugin. Do you plan to add EditorTweaks or the "old" Aligner?

maybe that's a better idea. Could you email me the code, you have my email address ;-)

What are all the thing the EditorTweaks can do ?
Title: Re: Doxygen plugin
Post by: MortenMacFly on June 24, 2010, 06:11:18 pm
maybe that's a better idea. Could you email me the code, you have my email address ;-)
True what danselmi said. The plugin is under SVN here:
http://svn.berlios.de/svnroot/repos/cbilplugin/branches/EditorTweaks

BTW: I believe I did some modifications in the project file... but I can fix such once it's in SVN (where I don't have the time for ATM...).
Title: Re: Doxygen plugin
Post by: Baluarte on June 28, 2010, 07:31:34 pm

And then we will create a nightly containing it.


I am truly anxious!  :lol:

Title: Re: Doxygen plugin
Post by: codeur on June 28, 2010, 11:33:02 pm
I am truly anxious!  :lol:
The word you were looking for is probably "eager", "impatient" or "keen".  :P
It's a good plugin, but it requires a bit of "polishing".
Title: Re: Doxygen plugin
Post by: Baluarte on June 29, 2010, 04:40:29 pm

"anxious": false friend.

B.

Title: Re: Doxygen plugin
Post by: Cryogen on July 06, 2010, 12:40:28 am
 Hi Guys,

Released version 1.6.596 of DoxyBlocks
-Fixed: Bugs that caused DoxyBlocks to crash when importing a Visual Studio solution.
-Added: Feature that allows you to load a saved template instead of the default settings, if no saved settings exist when loading a project. Requested by Codeur.
-Updated: Doxyfile output to doxygen 1.7.1.
-New: Prevented doxygen parse errors when using WXUNUSED() by adding it to doxygen's pre-processor settings.
-Updated: The document directory functionality to allow the use of directories other than "doxygen" as the root folder.
-Cleaned: The documentation to parse as cleanly as possible with all warnings enabled.
-Updated: Doxywizard's icon.

As you know, DoxyBlocks is about to become a contrib plug-in.  :P

I have fixed a couple of issues that were detected during final testing and added some new features that had been sidelined recently.
Codeur, with thanks for your infinite patience, your requested feature to auto-load a settings template is now a reality.
I have also modified the directory management functionality so that you can use a root directory other than "doxygen", as I realised that it is necessary when you inherit a project that uses something different, such as "doc", amongst other possibilities.
I finally managed to find a solution for the doxygen parse errors when WXUNUSED() is used. It requires using doxygen's pre-processor and is now generated automatically in the configuration file.
Finally, since doxywizard now has its own icon, I have changed DoxyBlocks to use that.

The latest docs are up on the SF site. Enjoy the new 1.7 look.

I will check these changes into my repository. This should be the last submission there. The SF repo will probably disappear once everything is up and running in C::B's SVN repo. I'm going to try building a .cbplugin against the V10.5 source so that there is a compatible version available for Windows users, at least. I will still need someone who can build on Linux with the standard libs to help with a Linux plug-in for 10.5.

Cheers,

  Cryo.


Title: Re: Doxygen plugin
Post by: Cryogen on July 06, 2010, 12:44:13 am

 Hi Surrealist,

Apologies for the slow response.

Hi Cryogen,

I'm no expert at this yet, but I did successfully rebuild Code::Blocks 10.05 for Windows.  I have also downloaded revision 34 of DoxyBlocks and rebuilt it from the source.  It
 ........
I hope this helps, and I'm happy to try to bundle this up in a better fashion if someone can give me a little coaching.

Thanks for the offer. Let me see what I come up with. It will probably be easier for me to just build it as I have the source here already.

Cheers.
Title: Re: Doxygen plugin
Post by: codeur on July 06, 2010, 04:30:42 am
Hi Guys,

Released version 1.6.596 of DoxyBlocks
-. . .
-Added: Feature that allows you to load a saved template instead of the default settings, if no saved settings exist when loading a project. Requested by Codeur.
-. . .
Cheers,

  Cryo.

Thank you Gary!
I am much obliged to you for DoxyBlocks. It's already been used a lot by students here and will be of huge service when Codeblocks-EP is publicly released and starts being used by other educational institutions (won't be long now.. a month and a bit. It'll be ready for when universities and colleges start again in the Northern hemisphere.).
Title: Re: Doxygen plugin
Post by: Cryogen on July 06, 2010, 11:45:24 pm

Thank you Gary!
I am much obliged to you for DoxyBlocks. It's already been used a lot by students here and will be of huge service when Codeblocks-EP is publicly released and starts being used by other educational institutions (won't be long now.. a month and a bit. It'll be ready for when universities and colleges start again in the Northern hemisphere.).

Always a pleasure. No small credit to you for your support and assistance. EP sounds good, nice one.  :wink:

Cheers.

Title: Re: Doxygen plugin
Post by: Cryogen on July 15, 2010, 02:33:37 am

 Hi Guys.

Version 1.6.606 is now available in the C::B SVN repository. There are just some minor formatting changes, this time, as we iron out the last few standardisation issues. We're just about there now. Very nice, too. :-)

Cheers,

  Gary.
Title: Re: Doxygen plugin
Post by: ironhead on July 16, 2010, 02:04:16 pm
Any chance on a 10.05 '.cbplugin' yet, or are you waiting on resolving the last few issues?
Title: Re: Doxygen plugin
Post by: Cryogen on July 19, 2010, 11:09:13 pm
Any chance on a 10.05 '.cbplugin' yet, or are you waiting on resolving the last few issues?

Yes and no. It still steadfastly refuses to work for me. I'm looking into whether I can either get a pre-built lib from one of the guys to link to or get one of them to build it. It's proving ridiculously difficult. If you can use SVN or a nightly build, I highly recommend doing so.

Sorry.
Title: Re: Doxygen plugin
Post by: polygon7 on July 20, 2010, 01:31:27 pm
Hi,
thank you for really cool plugin. :) I have some small suggestions - It would be great if you will add some integration with CodeCompletion plugin
and when somebody will press a key which inserts doxygen comment, DoxyBlocks will detect if in line below carret is function, or class, or struct
(or something else) and automatically insert proper doxygen comment. And another thing - it would be great if you will allow to make custom
"template" for doxygen comments (something like in astyle "source formatter" plugin have for formatting sources).
Title: Re: Doxygen plugin
Post by: ollydbg on July 20, 2010, 01:46:46 pm
Hi,
thank you for really cool plugin. :) I have some small suggestions - It would be great if you will add some integration with CodeCompletion plugin
and when somebody will press a key which inserts doxygen comment, DoxyBlocks will detect if in line below carret is function, or class, or struct
(or something else) and automatically insert proper doxygen comment. And another thing - it would be great if you will allow to make custom
"template" for doxygen comments (something like in astyle "source formatter" plugin have for formatting sources).

This is a good idea. Codecompletion plug-in has the ability to detect which function the caret was located in. or Which function is behind the caret.

If someone has the plan, I think I would like to help. :D
I think Doxygen has another engine to parse the source code. ( I have see its source code some days ago).
Title: Re: Doxygen plugin
Post by: Cryogen on July 20, 2010, 07:00:45 pm
 Hi there,

thank you for really cool plugin. :) I have some small suggestions - It would be great if you will add some integration with CodeCompletion plugin
and when somebody will press a key which inserts doxygen comment, DoxyBlocks will detect if in line below carret is function, or class, or struct
(or something else) and automatically insert proper doxygen comment. And another thing - it would be great if you will allow to make custom
"template" for doxygen comments (something like in astyle "source formatter" plugin have for formatting sources).

No problem, thanks. Well, it does that already via regular expressions, without CodeCompletion, but it could certainly be extended. For example, I don't think classes are detected at present and that should be easy to do. I have thought about a custom template but haven't looked at it. For me it's unnecessary but I'd like it to be as flexible as possible.

[EDIT] No, I was wrong, classes are detected. If you're expecting the docs to look like this:

Code
/*! \class Test class.h "inc/class.h"
 *  \brief This is a test class.
 *
...

then you'll be disappointed as that's only necessary for remote documentation, which DoxyBlocks isn't going to do for you. You might like to read a bit more about doxygen to understand what I mean, if necessary. DoxyBlocks can certainly create a default block for you and then you only need to insert the specific tag e.g. \class. Another way you might approach it is to create the documentation block at the item's location so that DoxyBlocks picks up the args, etc, then move it the remote location and add the type tag, e.g. \class. Unfortunately, there is no way that it can interpret every possible scenario.

Cheers.
Title: Re: Doxygen plugin
Post by: polygon7 on July 21, 2010, 07:05:55 pm
No problem, thanks. Well, it does that already via regular expressions, without CodeCompletion, but it could certainly be extended. For example, I don't think classes are detected at present and that should be easy to do. I have thought about a custom template but haven't looked at it. For me it's unnecessary but I'd like it to be as flexible as possible.
Hi,
I know doxygen tags and I can write it by hand but I'm bit lazy :) and it would be very helpful if DoxyBlock would insert basic tags for me automatically (this is what is missing for me in some older version of DoxyBlocks which I use), eg. for methods and functions.

Code
int foobar(int something, long other)
{
// Before DoxyBlocks
}

Code
/**
 * \since [current date]
 * \author [current user, or user-chosen value - something similar like ToDo plugin have]
 * \brief
 *
 * \param something -
 * \param other -
 *
 * \retval
 */
int foobar(int something, long other)
{
// After DoxyBlocks
}

and something similar for structures and classes (with \tparam) would be very nice:

Code
template
<
 class T,
 class TT,
 class TTT
>
class FooBar
{
// Before DoxyBlocks
};

Code
/**
 * \since [current date]
 * \class FooBar
 *
 * \author [current user, or user-chosen value - something similar like ToDo plugin have]
 * \brief
 *
 * \tparam T -
 * \tparam TT -
 * \tparam TTT -
 */
template
<
 class T,
 class TT,
 class TTT
>
class FooBar
{
// After DoxyBlocks
};

If DoxyBlocks support that already (I didn't update C::B to latest svn yet :P ), then sorry for noise and thanks again for great plugin.
Title: Re: Doxygen plugin
Post by: ollydbg on July 25, 2010, 01:50:50 pm
@polygon7
I have write my suggestions here about How does CC can support Doxygen. ( I wrote it here, because I hope others can benefit too :D)
Basically, When you caret are located here, before some functions:

Code
*** Your caret position A***
void functionXXX ( )
{
*** Your caret position B***
...
}

If your location is B, then I think in Codecompletions source code, you can easily find the Token around B. See the source snippet:
Code
int NativeParser::FindCurrentFunctionStart(cbEditor* editor, wxString* nameSpace, wxString* procName, int caretPos)
{
    ...

    TokenIdxSet result;
    size_t num_results = m_pParser->FindTokensInFile(editor->GetFilename(), result, tkFunction|tkConstructor|tkDestructor);
    if (s_DebugSmartSense)
        Manager::Get()->GetLogManager()->DebugLog(F(_T("FindCurrentFunctionStart() Found %d results"), num_results));

    TokensTree* tree = m_pParser->GetTokens();
    for (TokenIdxSet::iterator it = result.begin(); it != result.end(); ++it)
    {
        if (s_DebugSmartSense)
            Manager::Get()->GetLogManager()->DebugLog(_T("FindCurrentFunctionStart() (Next) Iteration..."));
        Token* token = tree->at(*it);
        if (token)
        {
            if (s_DebugSmartSense)
                Manager::Get()->GetLogManager()->DebugLog(F(_T("FindCurrentFunctionStart() Iterating: tN='%s', tF='%s', tStart=%d, tEnd=%d"),
                                                            token->DisplayName().wx_str(), token->GetFilename().wx_str(), token->m_ImplLineStart, token->m_ImplLineEnd));
            // found a matching function; check its bounds
            if (token->m_ImplLineStart <= (size_t)line && token->m_ImplLineEnd >= (size_t)line)
            {
                // got it :)
                if (s_DebugSmartSense)
                    Manager::Get()->GetLogManager()->DebugLog(F(_T("FindCurrentFunctionStart() Current function: '%s' (at line %d)"),
                                                                token->DisplayName().wx_str(),
                                                                token->m_ImplLine));

                s_LastNS     = token->GetNamespace();
                s_LastPROC   = token->m_Name;
                s_LastResult = control->PositionFromLine(token->m_ImplLine - 1);

                // locate function's opening brace
                while (s_LastResult < control->GetTextLength())
                {
                    wxChar ch = control->GetCharAt(s_LastResult);
                    if (ch == _T('{'))
                        break;
                    else if (ch == 0)
                    {
                        if (s_DebugSmartSense)
                            Manager::Get()->GetLogManager()->DebugLog(_T("FindCurrentFunctionStart() Can't determine functions opening brace..."));
                        return -1;
                    }

                    ++s_LastResult;
                }

                if (nameSpace) *nameSpace = s_LastNS;
                if (procName)  *procName  = s_LastPROC;

                if (s_DebugSmartSense)
                    Manager::Get()->GetLogManager()->DebugLog(F(_T("FindCurrentFunctionStart() Namespace='%s', proc='%s' (returning %d)"),
                                                                s_LastNS.wx_str(), s_LastPROC.wx_str(), s_LastResult));
                return s_LastResult;
            }
            else if (s_DebugSmartSense)
                Manager::Get()->GetLogManager()->DebugLog(F(_T("FindCurrentFunctionStart() Function out of bounds: tN='%s', tF='%s', tStart=%d, tEnd=%d, line=%d (size_t)line=%d"),
                                                            token->DisplayName().wx_str(), token->GetFilename().wx_str(), token->m_ImplLineStart, token->m_ImplLineEnd, line, (size_t)line));
        }
    }

    if (s_DebugSmartSense)
        Manager::Get()->GetLogManager()->DebugLog(_T("FindCurrentFunctionStart() Can't determine current function..."));

    s_LastResult = -1;
    return -1;
}

Note that all the Token information was in TokensTree, so, first, you need to get all the tokens belong to the current file, this is done by calling:

Code
    TokenIdxSet result;
    size_t num_results = m_pParser->FindTokensInFile(editor->GetFilename(), result, tkFunction|tkConstructor|tkDestructor);
The last argument is a mask. If you want to other information, you can change the "mark".

Onec you get the result, you just do a loop on it and find which Token covers your current line.

Finally, you find some one, for my example, you will find the Token " void functionXXX ( ) ", so, you can do everything you like to do.  :D


If you caret is located in position A, I think you can still do the loop in the result, and find the nearest token behind your current line.  :D

Title: Re: Doxygen plugin
Post by: polygon7 on July 25, 2010, 02:04:05 pm
@polygon7
I have write my suggestions here about How does CC can support Doxygen. ( I wrote it here, because I hope others can benefit too :D)

Thanks! :)
Title: Re: Doxygen plugin
Post by: rah2435 on July 30, 2010, 05:26:15 pm
Anything new on this?

I'm getting the same "missing symbols?" error when trying to install the plugin in C::B version 10.05 on both Ubuntu 10.04 and Windows 7.

I downloaded the plugin file...do I need other files as well? 
Title: Re: Doxygen plugin
Post by: Jenna on July 30, 2010, 07:49:53 pm
On ubuntu you can use my repo, but you need the wxwidgets packages from apt.wxwidgets.org, because the ubuntu libs are not compatible with the libs provided by the wxwidgets devs themselves.
Yesterday I downloaded svn r6435 that includes Doxigen plugin (and some others).
Title: Re: Doxygen plugin
Post by: Cryogen on August 06, 2010, 10:32:28 pm

 Hi,

Anything new on this?

I'm getting the same "missing symbols?" error when trying to install the plugin in C::B version 10.05 on both Ubuntu 10.04 and Windows 7.

I downloaded the plugin file...do I need other files as well? 

If you read through the history you'll see that there is currently no compatible .cbplugin for any release version, let alone 10.5. I'm still chasing killerbot to build one but I'm also without a computer at present (it died!! :-() so it's not happening quickly.

Cheers.
Title: Re: Doxygen plugin
Post by: stahta01 on August 07, 2010, 03:39:49 am
My attempt to make an plugin worked; but I have no idea if the plugin works.

The plugin loaded on my Windows 7 32 computer.

Anyone have a site I can upload the Windows Doxygen Plugin to or an email address of a person who wants to test the plugin?

The file is about 700k in size.

Tim S.
Title: Re: Doxygen plugin
Post by: Cryogen on August 24, 2010, 10:26:46 pm

 Hey Tim,

My attempt to make an plugin worked; but I have no idea if the plugin works.

The plugin loaded on my Windows 7 32 computer.

Anyone have a site I can upload the Windows Doxygen Plugin to or an email address of a person who wants to test the plugin?

Apologies for the slow response, I've been in purgatory without a computer for 5 weeks or so.  :cry:

I'd be happy to do those things for you. You can send me the details via PM here or the SF address. If you can't attach files to either, just let me know where I can grab it from, attach it here, or something suitable. I'll put on the existing SF site it it works.

Thanks.
Title: Re: Doxygen plugin
Post by: Cryogen on September 03, 2010, 06:50:21 am

 Hi Guys,

This is just a note to advise that the SourceForge project at https://sourceforge.net/projects/doxyblocks/ and the docs at http://doxyblocks.sourceforge.net/ have been abandoned, since they no longer serve a useful purpose. The old docs have been removed. The docs are now at the wxSmith Addons site listed below. The .cbplugin file releases have been removed to avoid confusion as they never worked for anyone else anyway. The project itself and the old SVN repository will remain for posterity but there will be no further updates. Development is now occurring in the Code::Blocks SVN repository. If and when I manage to obtain .cbplugins for V10.5, they will go on the wxSmith Addons site.

Thanks,

  Cryo.

Title: Re: Doxygen plugin
Post by: ollydbg on September 04, 2010, 08:45:24 am
Here is my test on doxygen, which I just right click on the function name and would like to add the block comment

Quote
        /** \brief
         *
         * \param
         * \param
         * \return
         *
         */                                                     
        size_t FindAIMatches(std::queue<ParserComponent> components,
                             TokenIdxSet& result,
                             int parentTokenIdx = -1,
                             bool fullMatch = false,
                             bool caseSensitive = false,
                             bool use_inheritance = true,
                             short int kindMask = 0xFFFF,
                             TokenIdxSet* search_scope = 0);


        /** \brief
         *
         * \param actual const wxString&
         * \param components std::queue<ParserComponent>&
         * \return size_t
         *
         */                                                     
        size_t BreakUpComponents(const wxString& actual, std::queue<ParserComponent>& components);

So,
1, I guess the function parameter in multiply lines are not supported.
2, I think we don't need to add the "type" information , so "\param actual" is enough.

any comments?
Title: Re: Doxygen plugin
Post by: Cryogen on September 05, 2010, 11:53:18 pm

 Hi Olly,

Here is my test on doxygen, which I just right click on the function name and would like to add the block comment

So,
1, I guess the function parameter in multiply lines are not supported.
2, I think we don't need to add the "type" information , so "\param actual" is enough.

any comments?


1. No, it's not, I'm afraid and I was unable to make it work.

2. I don't know what you mean, here.

Cheers.
Title: Re: Doxygen plugin
Post by: ollydbg on September 06, 2010, 01:15:43 am
2. I don't know what you mean, here.
thanks for the reply and sorry for my bad English.

I mean that

Code
/** \brief
         *
         * \param actual const wxString&
         * \param components std::queue<ParserComponent>&
         * \return size_t
         *
         */                                                     
        size_t BreakUpComponents(const wxString& actual, std::queue<ParserComponent>& components);

should be:
Code
/** \brief
         *
         * \param actual
         * \param components
         * \return size_t
         *
         */                                                     
        size_t BreakUpComponents(const wxString& actual, std::queue<ParserComponent>& components);
Not type information about the parameter is need. (this is most comment style in codeblocks' source).
Title: Re: Doxygen plugin
Post by: Cryogen on September 08, 2010, 09:33:08 pm

 Hi Guys,

I am happy to report that, at long last, I now have a .cbplugin for 10.5 on Windows. It's available from:

http://wxsmithaddons.sourceforge.net/doxyblocks.html

Many thanks to my main man killerbot for building it. I'm sure it will be appreciated by those who have been waiting for it. I will try and coerce Jens into making one for Linux to complete the set.

Cheers,

 Gary.
Title: Re: Doxygen plugin
Post by: Cryogen on September 08, 2010, 09:43:57 pm
2. I don't know what you mean, here.
thanks for the reply and sorry for my bad English.

I mean that

Code
/** \brief
         *
         * \param actual const wxString&
         * \param components std::queue<ParserComponent>&
         * \return size_t
         *
         */                                                     
        size_t BreakUpComponents(const wxString& actual, std::queue<ParserComponent>& components);

should be:
Code
/** \brief
         *
         * \param actual
         * \param components
         * \return size_t
         *
         */                                                     
        size_t BreakUpComponents(const wxString& actual, std::queue<ParserComponent>& components);
Not type information about the parameter is need. (this is most comment style in codeblocks' source).

OK, got it. Please don't apologise, my brain's getting old. I think that what is "most common" probably depends on experience and other factors. There's no way DoxyBlocks can ever deal with every possible code format or please everyone. I seem to remember getting the existing form from doxyblocks docs but I see that it's different in the current version. Maybe it changed or maybe it came from the original script, I really can't recall. If there was a consensus that a specific format was wanted, we could certainly change it. What you can do is modify your copy to produce the output you want, though. It should be fairly straightforward and I'm happy to help you if required. Just yell.

Gary.


Title: Re: Doxygen plugin
Post by: killerbot on September 08, 2010, 09:50:25 pm
Hi Gary,
to be honest this is the first time is saw that the type information was added.

My feeling is, no need to specify the type information (another thing to change when the parameter would become a different type).
Title: Re: Doxygen plugin
Post by: MortenMacFly on September 09, 2010, 06:14:27 am
My feeling is, no need to specify the type information (another thing to change when the parameter would become a different type).
I agree here, as usually Doxygen handles that for you anyways. I'd say the variable name is enough.
Title: Re: Doxygen plugin
Post by: koso on November 04, 2010, 01:18:39 pm
Hi,

its hard to describe ... but is it possible to configure plugin (update source) so that inserting block comment is one unite editor action and can be removed using one "undo"? Now it needs much more undo operations to return to the state before inserting comment, which is especially annoying in case of accidental comment insertion :)
Title: Re: Doxygen plugin
Post by: Jenna on November 04, 2010, 01:48:57 pm
Hi,

its hard to describe ... but is it possible to configure plugin (update source) so that inserting block comment is one unite editor action and can be removed using one "undo"? Now it needs much more undo operations to return to the state before inserting comment, which is especially annoying in case of accidental comment insertion :)
Yes it's quite easy.

I attach a patch against actual trunk.

@Gary:
can I commit the patch or do you want to review it and update your svn-repo first, if you accept the patch ?
Title: Re: Doxygen plugin
Post by: Cryogen on November 06, 2010, 07:26:37 pm

 Hi Jens,

No, you go ahead. My SF repo. is defunct, now.

Thanks.
Title: Re: Doxygen plugin
Post by: Jenna on November 07, 2010, 08:53:51 am

 Hi Jens,

No, you go ahead. My SF repo. is defunct, now.

Thanks.

Done in svn r6840 .
Title: Re: Doxygen plugin
Post by: NefX on November 08, 2010, 07:24:15 pm
I agree here, as usually Doxygen handles that for you anyways. I'd say the variable name is enough.
Yeah, you can see type name already so it's not needed.

Two things I would like to see -  code completion displaying doxygen comments and automatic adding e.g. '///' when making new line (inside doxygen comment).  By the way how to change default hotkeys from this plugin?
Title: Re: Doxygen plugin
Post by: Folco on November 14, 2010, 11:50:12 am
First time I use your plugin Cryogen. It's very efficient, good job and thank you !
Title: Re: Doxygen plugin
Post by: Cryogen on November 20, 2010, 02:35:40 am
First time I use your plugin Cryogen. It's very efficient, good job and thank you !

[Admin: Removed non-english content.]

I'm glad you found it useful.

Cheers.
Title: Re: Doxygen plugin
Post by: koso on December 20, 2010, 03:44:02 pm
Hi,

it seems that plugin has problem with commenting multiline function/procedure declarations. It adds block comment, but parameter names (and types) are missing. For example:

Code
    /** @brief 
     *
     * @param
     * @param
     * @return
     *
     */                             
    void handle_write(const int error,
                      long bytes_transferred)


but I expected this:

Code
    /** @brief 
     *
     * @param error const int
     * @param bytes_transferred long
     * @return void
     *
     */                             
    void handle_write(const int error, long bytes_transferred)

Title: Re: Doxygen plugin
Post by: Cryogen on December 29, 2010, 03:07:39 am
Hi,

it seems that plugin has problem with commenting multiline function/procedure declarations. It adds block comment, but parameter names (and types) are missing. For example:


Yes, quite right. I could find no way to make it accommodate them. I still can't, unfortunately.

The barely useful work-around is to condense the declaration to one line, generate the comment, then revert it.

Cheers.
Title: Re: Doxygen plugin
Post by: codeur on January 03, 2011, 10:36:14 pm
Hi Cryogen,
I just hit a minor bug in DoxyBlocks:
When saving the documentation into a place different from the standard "doxygen" directory and clicking "Extract documentation" in the DoxyBlocks menu, the final message is "Your documents are in: ..\..\..\..\doxygen\ (the default documentation directory) which is incorrect. The documentation is however properly saved in the requested place.

When clicking "Run HTML" or "Run CHM" in the menu, the path to the documantation is also incorrect and the run does not succeed.

Of course, the documentation path shown is correct when Doxywizard is used instead and "show HTML output" works from there.

The portable CB launcher just released ( http://forums.codeblocks.org/index.php/topic,10360.msg93976.html#msg93976 ) comes with its own doxyfile and exhibits this issue.

Title: Re: Doxygen plugin
Post by: Cryogen on February 03, 2011, 05:25:14 am

 Hey Codeur,

Hi Cryogen,
I just hit a minor bug in DoxyBlocks:
When saving the documentation into a place different from the standard "doxygen" directory and clicking "Extract documentation" in the DoxyBlocks menu, the final message is "Your documents are in: ..\..\..\..\doxygen\ (the default documentation directory) which is incorrect. The documentation is however properly saved in the requested place.

I'm afraid that's rather too vague. I'll need specific steps to reproduce it including exactly how you're setting the path.

Thanks for reporting.

Title: Re: Doxygen plugin
Post by: Cryogen on February 03, 2011, 05:31:39 am
 Hi guys,

Released version 1.6.614 of DoxyBlocks
-Updated: doxygen support to v1.7.3.
-Removed some compiler warnings under gcc4.5.

Cheers.
Title: Re: Doxygen plugin
Post by: codeur on February 03, 2011, 06:20:22 am

 Hey Codeur,

Hi Cryogen,
I just hit a minor bug in DoxyBlocks:
When saving the documentation into a place different from the standard "doxygen" directory and clicking "Extract documentation" in the DoxyBlocks menu, the final message is "Your documents are in: ..\..\..\..\doxygen\ (the default documentation directory) which is incorrect. The documentation is however properly saved in the requested place.

I'm afraid that's rather too vague. I'll need specific steps to reproduce it including exactly how you're setting the path.

Thanks for reporting.

Fair enough Gary,

The path to the output directory is set in the doxyfile by using the doxywizard (project -> expert tab). Doxyblocks appears decoupled from the doxyfile for this path. If you try the example in the project I mentioned earlier, you'll see (by using the wizard) that the output directory is set relative to the doxyfile as ../doc. Doxyblocks does not take this into account and assumes that the output directory is the default "doxygen" subdirectory.

To reproduce the problem the example project accessed from: http://forums.codeblocks.org/index.php/topic,10360.msg93976.html#msg93976 comes with its own doxyfile and exhibits this issue.
To see the problem you must load the example project project then click "Extract documentation" in the DoxyBlocks menu. The final message is "Your documents are in: ..\..\..\..\doxygen\ -which is inexact.
If you then click "Run HTML" or "Run CHM" in the Doxyblocks menu, you can also see that the path to the documentation assumed by Doxyblocks is incorrect and that therefore the run does not succeed.

Thanks for the new version release.
Title: Re: Doxygen plugin
Post by: Cryogen on February 05, 2011, 05:01:36 pm

Well, I wasn't actually asking you to repeat what you'd already said, albeit slowly. I wanted to repeat how you set that project up in my test env. Nonetheless, it works for me:

Code
Success.
Your documents are in: C:\Utilities\Code\CbLauncher_0.1.5\CbLauncher\doxygen\

Done.

HTML Help not found at C:\Utilities\Code\CbLauncher_0.1.5\CbLauncher\doxygen\CbLauncher.chm.
Default browser launched with URL file://C:\Utilities\Code\CbLauncher_0.1.5\CbLauncher\doxygen\html/index.html.

Latest C::B. lates DoxyBlocks, Win7.
The CHM is not configured to build, so that's normal. The HTML ran first time. So, I think you use Windows, don't you? How did you set the path? DoxyBlocks? doxywizard? Anything else?

Thanks for the new version release.

My pleasure. :-)

Ciao.
Title: Re: Doxygen plugin
Post by: codeur on February 06, 2011, 05:14:02 am
DoxyBlocks is misbehaving here without any doubt, but your test did not present it with the issue in question.

To reproduce the issue:
- load the provided example project into codeblocks,
- press "Extract Documentation" in the Doxyblocks menu to get the success message, then
- press "Run HTML" in the Doxyblocks menu to obtain the "Index.html not found" message.
You obtain:
Code
Extracting documentation for CbLauncher.
DoxyBlocks is working, please wait a few moments...
Found existing doxyfile...
Success.
Your documents are in: C:\Temp\CbLauncher\doxygen\

Done.

Index.html not found at C:\Temp\CbLauncher\doxygen\html/index.html.

The provided project doxyfile specifies the output directory as ../doc
Doxygen does the right thing and generates the documentation in ..\doc
DoxyBlocks is unaware of this output directory and assumes that the documentation is in the default "doxygen" subdirectory.

For how that output path was set originally for this project:
The path to the output directory is set in the doxyfile by using the doxywizard (project -> expert tab).
The output directory ../doc was originally entered in the "output directory" field on that page.

Latest Codeblocks, latest Doxyblocks, XP (the issue was the same with previous versions of Codeblocks and previous versions of DoxyBlocks).
I think you must have re-generated a new doxyfile and therefore erased the output path from the project doxyfile prior to your test, so it could not show the issue.

If it is too much work to fix this issue, I can personally live with it. It's not a big hassle.
Title: Re: Doxygen plugin
Post by: Cryogen on February 06, 2011, 05:48:05 am
I think you must have re-generated a new doxyfile and therefore erased the output path from the project doxyfile prior to your test, so it could not show the issue.

Yes, you're right. I see the problem now. I'll look into it.

Thanks.
Title: Re: Doxygen plugin
Post by: Cryogen on February 06, 2011, 11:30:38 pm

 Hey Codeur,

I've discovered what's going on here. There are several parts to it. Firstly, when you use something other than "doxgen" as the doc dir. you need to set the OUTPUT_DIRECTORY field on the "Doxygen Defaults" tab. The help tooltip explains the options. At the same time, DoxyBlocks doesn't support having the doxyfile in one place and the docs in another. The problem is that it looks at its prefs to determine the output dir., not in the doxyfile, and it assumes that that is where the doxyfile lives, too.

So, firstly, while I think that DoxyBlocks should support that, since doxygen does, it will take some work reviewing all of the path management code and I don't have time to do that at present. Secondly, I have fixed a bug or two and made some improvements. You can still run things as you are now, if you wish, but DoxyBlocks won't run the docs. If you enter the path in the prefs, DoxyBlocks will write a new doxyfile there, ignore the doxygen dir. and then behave correctly, although not exactly as you desire. The best solution is to move your doxfile to ../doc and then everything will be reported and run correctly without any intervention. If you are happy with that, I think you are in business.

I will create a TODO item for posterity. The patch will be available shortly.

Thanks again.

Title: Re: Doxygen plugin
Post by: Cryogen on February 06, 2011, 11:40:45 pm
Released version 1.7.655 of DoxyBlocks
-Fixed: Hard coded doxygen directory name.
-Updated: Directory creation code.

Patch available from the Patchorama link below.

Cheers.

Title: Re: Doxygen plugin
Post by: codeur on February 07, 2011, 01:13:19 am
Thanks for the update Gary,
I'll place the doxyfile with the documents, no problem.
But before I can try that I need to find your patch. I searched for it on the wxsmith_addons branch on berlioz without luck. Can you give me a more precise hint of where it is?
EDIT: I have found it, thanks.
Title: Re: Doxygen plugin
Post by: MortenMacFly on February 07, 2011, 07:06:54 am
Can you give me a more precise hint of where it is?
Doxyblocks is not related to the wxSmith branch as it is already part of the contrib plugins. Have a look at Cryogens "patchorama" (http://forums.codeblocks.org/index.php/topic,12619.msg95229/topicseen.html#msg95229) or at BerliOS, the patch tracker of C::B (http://developer.berlios.de/patch/?func=detailpatch&patch_id=3127&group_id=5358).
Title: Re: Doxygen plugin
Post by: codeur on February 07, 2011, 12:38:55 pm
Doxyblocks is not related to the wxSmith branch as it is already part of the contrib plugins...
Thanks Morten,
It looks like that latest patch is provided relative to the last version in the wxSmith branch, not relative to the version in trunk.
I'll wait to proceed until either trunk is updated with those last modifications or a patch relative to trunk is provided.
Title: Re: Doxygen plugin
Post by: MortenMacFly on February 07, 2011, 02:12:56 pm
I'll wait to proceed until either trunk is updated with those last modifications or a patch relative to trunk is provided.
I've tried myself and it seems this patch is broken I cannot apply it at all: Neither to trunk nor the branch. I've asked for a new patch in the patch tracker accordingly.
Title: Re: Doxygen plugin
Post by: Cryogen on February 22, 2011, 01:57:08 am
 
Hey Morten,

Is this one still problematic?

Thanks.
Title: Re: Doxygen plugin
Post by: MortenMacFly on February 22, 2011, 05:43:22 pm
Is this one still problematic?
Yes. It does not apply at all. :-(

Hey - this is already applied ! :-)
Title: Re: Doxygen plugin
Post by: codeur on February 22, 2011, 10:41:27 pm
Patch #3127 was applied on 8 February. I built and tested the new version (1.7.655).
The repair is only partial and the issue is not fixed.
DoxyBlocks still does not properly handle output documents located elsewhere than in the doxygen folder (even when the doxyfile is in that "other" output folder).
Title: Re: Doxygen plugin
Post by: Cryogen on February 23, 2011, 04:39:11 am
Is this one still problematic?
Yes. It does not apply at all. :-(

Hey - this is already applied ! :-)

Yes and no. I see the problem. For some reason, the second version of the patch missed a bunch of stuff. Something seems to be going on with patch creation in Tortoise. I'll upload take 3. Ergh.
Title: Re: Doxygen plugin
Post by: Cryogen on February 23, 2011, 04:45:56 am
Patch #3127 was applied on 8 February. I built and tested the new version (1.7.655).
The repair is only partial and the issue is not fixed.

Yes. See the previous response

DoxyBlocks still does not properly handle output documents located elsewhere than in the doxygen folder (even when the doxyfile is in that "other" output folder).

That will improve somewhat once we get all the changes in place, however, you might reconsider your use of the word "properly". As explained in detail below, it still won't do exactly what you're after as it wasn't designed to do so. I don't consider your approach "proper" use of doxygen but I respect your right to do things as you wish. I always try and build in maximum flexibility, this ain't Microsoft, but I don't have the time to address your request in full at present. Feel free to improve things.

Cheers.


Title: Re: Doxygen plugin
Post by: codeur on February 23, 2011, 05:50:07 am
Patch #3127 was applied on 8 February. I built and tested the new version (1.7.655).
The repair is only partial and the issue is not fixed.

Yes. See the previous response
... however, you might reconsider your use of the word "properly". As explained in detail below, it still won't do exactly what you're after as it wasn't designed to do so.

I understand Gary. I have read your previous posts and for me "properly" for now includes the restriction that we need to have the doxyfile inside the output documentation folder. I'll live with this minor constraint for now.
As you suggest I will indeed hop on board in a few months when I have a bit of time. I'll then provide patches to enable those few refinements that are not yet in by then, like the possibility of having separate doxygen setup and output documentation folders.
That's not a worry.

DoxyBlocks is great and a huge help as it is. It has been used a lot around here and is VERY useful in educational environments. Programming students who would normally skip all documentation get into the habit of documenting their code thanks to it and to you. Have a look at the latest version of CodeBlocks-EP if you have the time.
Title: Re: Doxygen plugin
Post by: Cryogen on February 26, 2011, 02:50:38 am
 Hi Codeur,

Thanks, that's great. I'm happy to look at improving things when I get the time, as well. I think it will require a revision of all of the path management code as it wasn't written with that in mind. It shouldn't be an earth-shattering change, though, it just needs some time.

CodeBlocks-EP is very cool. I will do that. :-)

Cheers.
Title: Re: Doxygen plugin
Post by: youarefunny on March 08, 2011, 05:24:14 am
I noticed that this plug-in creates the doxygen config file as 'doxyfile' instead of doxygens default 'Doxyfile'.  Could this be changed please.

Oh, pan by the way great plug-in :)

I can see the future of this plug-in extracting the documentation and having fly-outs as you highlight a function in auto-complete and by right clicking on things.  Keep up the good work.
Title: Re: Doxygen plugin
Post by: ptDev on March 08, 2011, 09:41:00 am
I can see the future of this plug-in extracting the documentation and having fly-outs as you highlight a function in auto-complete and by right clicking on things.  Keep up the good work.

The best way to implement this would be allowing CodeCompletion to parse doxygen documentation.
Title: Re: Doxygen plugin
Post by: oBFusCATed on March 08, 2011, 09:59:44 am
Or provide some hooks to enable different styles of documentation...
Title: Re: Doxygen plugin
Post by: MortenMacFly on March 24, 2011, 11:21:37 am
...I got another feature request:
Doxygen (while compiling) complains about missing documentation like missing variables or wrong spelled variables. It would be nice to have a log window where these messages are piped into and where you can click on the messages and jump to the line in the file (similar like the build log).
Title: Re: Doxygen plugin
Post by: oBFusCATed on March 24, 2011, 12:54:55 pm
Why not use the build log directly, there are too many logs already:)
Title: Re: Doxygen plugin
Post by: killerbot on March 24, 2011, 02:40:54 pm
before I forget, in on e of the last changes something got broken, with respect to output directory or position position of the cbp file or the doxygen file. It used to work before, now it no longer works. Gonna try to post a little project here, showcasing the failure this evening,
Title: Re: Doxygen plugin
Post by: killerbot on March 24, 2011, 08:11:16 pm
here's a project that now fail with the doxygen plugin, where it used to work in the past.

Quote
----------------------------------------------------------------------------------------------------
Extracting documentation for Test.
DoxyBlocks is working, please wait a few moments...
Writing doxyfile...
Failed. /home/killerbot/Projects/Test/Project/doxygen/doxyfile was not created.

Done.

Note that the "doxygen" directory is created
Title: Re: Doxygen plugin
Post by: gd_on on May 09, 2011, 05:58:53 pm
Here is a small Hello standard program. Results with Doxybloacks are not those I expect.

cbp file is inside a make folder. main.c and version.h are in src.
Autoversioning plugin finds correctly version.h, but Doxyblocks when configured to use it, does not seem to find version.h. More, it tries to locate it at a wrong place.
svn 7141, Win XP, SP3.

And in the result, version.h is in the file list, but not main.c (totally different problem here ?).

Bug or I'm missing something ?

Gd_on
Title: Re: Doxygen plugin
Post by: Derjik on February 12, 2013, 09:54:52 pm
Hello again,

I hope this is the appropriate thread to talk about eventual (small) "issues" with DoxyBlocks... if not, I'm really sorry, and I understand my post could be deleted.

So:
As i said in this thread (http://forums.codeblocks.org/index.php/topic,15701.0.html), I'm running C::B 12.11 on Windows 7 Pro and while "everything's fine" with DoxyWizard itself for extracting the documentation, the "Extract Documentation" item from DoxyBlocks doesn't seem to do anything...
It just creates a small doxyfile if no existing one is found, else it "detects" it, but doesn't extract anything. (and the doxyfile I use in my currect projet is valid, as DoxyWizard managed to extract the documentation).

So this isn't a "harmful" problem, but I like the idea of "just using a keyboard shortcut" whenever I want to extract (or "update") my documentation... and I don't know what I'm doing wrong with DoxyBlocks.
Any help welcome, so thanks by advance, and sorry if I'm not in the right thread :|


EDIT: As I said in the other topic, we found more details on this problem: The "Extract Documentation" feature cannot handle special characters in the working path (and I'm working under "Mes Documents", so the blank caused the trouble for me...).
I don't know if we can call it "a bug", but... it's said.
Title: Re: Doxygen plugin
Post by: Joerg on July 04, 2013, 09:26:59 am
Hi,
I would like to suggest another template for block comments without the trailing stars:
Code
/** \brief 

 \param
 \param
 \return

 */
It's easier to edit, as long as C::B does not fill in the stars, as eclipse is doing ;-)
Title: Re: Doxygen plugin
Post by: ronwww on September 13, 2013, 06:32:57 pm
Is DoxyBlocks still being worked on?

Is doxyblocks.sourceforge.net still the project home or is it now maintained in wxsmithaddons.sourceforge.net/docs/doxyblocks ?
Title: Re: Doxygen plugin
Post by: oBFusCATed on September 13, 2013, 07:07:11 pm
http://sourceforge.net/p/doxyblocks/code/37/
Title: Re: Doxygen plugin
Post by: goranj on August 29, 2014, 07:51:10 am
Hi,
I installed V13.12, it looks like DoxyBlock plugin is not installed - I checked the manual and list of installed plugins but doxyBlock is not mentioned and it is not on the list of installed plugins.
How can I install it?
Thanks for your help.
Regards
Title: Re: Doxygen plugin
Post by: oBFusCATed on August 29, 2014, 09:38:51 am
Re-install and make sure you've enabled all plugins!
Title: Re: Doxygen plugin
Post by: goranj on August 29, 2014, 11:36:50 am
Re-install and make sure you've enabled all plugins!

Much obliged oBFusCATed
Title: Re: Doxygen plugin
Post by: Feneck91 on October 16, 2014, 08:36:54 am
I have updated Doxyblocks with latest nightly build SVN 9958. I generate doc :
Code
/** \mainpage wxETKSQLite3

\section intro What is wxETKSQLite3?

    \b wxETKSQLite3 is a C++ wrapper around the public domain
    written in C++ that allow to access <a href="http://www.sqlite.org/">SQLite3</a> database.<br>
    This library is used to allow user to quickly make database binding and make easy request with C++ operators
    and is specifically designed for use in programs based on the \b <a href="http://www.wxwidgets.org/">wxWidgets</a> library.
    A workaround has been made to make it works with \b <a href="http://qt.nokia.com/products/">QT</a> Library.<br>

But when I generate it, it generate HTML with \b or
Code
<dl>
<dt><b>1.1</b> - <i>02 July 2012</i></dt>
<dd>
QT Integration...
</dd>
<dt><b>1.0</b> - <i>12 December 2011</i></dt>
<dd>
First release - Not published...
</dd>
</dl>
Something has been chenged, an option to check to correctly generate HTML documentation ?
Title: Doxygen Plugin Template Location
Post by: Thoth on November 07, 2018, 07:27:47 pm
Hello,

Where are the templates stored for the different Doxygen comment styles? I would like to modify one of them.
I am using C::B version 17.12 with DoxyBlocks version 1.7.3 on FreeBSD 11.2.

A quick look at http://wiki.codeblocks.org/index.php/DoxyBlocks does not reveal where the templates might be located. Nor does
Code
locate codeblocks | grep -i "Doxy"

I also searched the forum but either I missed it or did not get what I was looking for in the results.

Also, I really appreciate the effort to get DoxyBlocks integrated. Thank you all that worked on it.


=thoth=