Author Topic: Doxygen plugin  (Read 173381 times)

Offline Cryogen

  • Regular
  • ***
  • Posts: 260
Re: Doxygen plugin
« Reply #150 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.

Offline codeur

  • Multiple posting newcomer
  • *
  • Posts: 113
    • Code::Blocks EDU-Portable
Re: Doxygen plugin
« Reply #151 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.

« Last Edit: April 07, 2010, 01:13:07 am by codeur »

Offline Cryogen

  • Regular
  • ***
  • Posts: 260
Re: Doxygen plugin
« Reply #152 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.


Offline codeur

  • Multiple posting newcomer
  • *
  • Posts: 113
    • Code::Blocks EDU-Portable
Re: Doxygen plugin
« Reply #153 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.

caoselee

  • Guest
Re: Doxygen plugin
« Reply #154 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. :?

Offline Cryogen

  • Regular
  • ***
  • Posts: 260
Re: Doxygen plugin
« Reply #155 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.

Offline Cryogen

  • Regular
  • ***
  • Posts: 260
Re: Doxygen plugin
« Reply #156 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: [Select]
/** \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: [Select]
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.

Offline codeur

  • Multiple posting newcomer
  • *
  • Posts: 113
    • Code::Blocks EDU-Portable
Re: Doxygen plugin
« Reply #157 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?

Offline maofde

  • Single posting newcomer
  • *
  • Posts: 8
Re: Doxygen plugin
« Reply #158 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.

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: Doxygen plugin
« Reply #159 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.


Offline maofde

  • Single posting newcomer
  • *
  • Posts: 8
Re: Doxygen plugin
« Reply #160 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:-(

Offline Cryogen

  • Regular
  • ***
  • Posts: 260
Re: Doxygen plugin
« Reply #161 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.

Offline Phenom

  • Multiple posting newcomer
  • *
  • Posts: 57
Re: Doxygen plugin
« Reply #162 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.

Offline Cryogen

  • Regular
  • ***
  • Posts: 260
Re: Doxygen plugin
« Reply #163 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.

Offline Cryogen

  • Regular
  • ***
  • Posts: 260
Re: Doxygen plugin
« Reply #164 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.