Author Topic: Doxygen plugin  (Read 188394 times)

Offline Cryogen

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

Offline maofde

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

Offline Cryogen

  • Regular
  • ***
  • Posts: 260
Re: Doxygen plugin
« Reply #122 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: [Select]
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.
« Last Edit: March 28, 2010, 07:22:10 pm by Cryogen »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9508
Re: Doxygen plugin
« Reply #123 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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline codeur

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

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9508
Re: Doxygen plugin
« Reply #125 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: [Select]
PROJECT_NAME           = Code::Blockswould become:
Code: [Select]
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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline Cryogen

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


Offline Cryogen

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

Offline Cryogen

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

Offline Cryogen

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

Online stahta01

  • Lives here!
  • ****
  • Posts: 6672
    • My Best Post
Re: Doxygen plugin
« Reply #130 on: April 01, 2010, 10:39:16 pm »
Contented Delete to improve tone of there.
« Last Edit: April 03, 2010, 06:19:36 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Cryogen

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

Online stahta01

  • Lives here!
  • ****
  • Posts: 6672
    • My Best Post
Re: Doxygen plugin
« Reply #132 on: April 02, 2010, 07:03:55 pm »
Contented Delete to improve tone of there.
« Last Edit: April 03, 2010, 06:20:04 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline ptDev

  • Almost regular
  • **
  • Posts: 222
Re: Doxygen plugin
« Reply #133 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.

Offline Cryogen

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