Author Topic: Doxygen plugin  (Read 182643 times)

Offline Cryogen

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

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6612
    • My Best Post
Re: Doxygen plugin
« Reply #136 on: April 03, 2010, 12:20:08 am »
Contented Delete to improve tone of there.
« Last Edit: April 03, 2010, 06:20:45 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 codeur

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

Offline Cryogen

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

Offline Cryogen

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

Offline Cryogen

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


Offline codeur

  • Multiple posting newcomer
  • *
  • Posts: 113
    • Code::Blocks EDU-Portable
Re: Doxygen plugin
« Reply #141 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.
« Last Edit: April 03, 2010, 01:50:40 am by codeur »

Offline codeur

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

Offline codeur

  • Multiple posting newcomer
  • *
  • Posts: 113
    • Code::Blocks EDU-Portable
Re: Doxygen plugin
« Reply #143 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.
« Last Edit: April 03, 2010, 06:44:57 am by codeur »

Offline Cryogen

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

Offline Cryogen

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



Offline Cryogen

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

Offline codeur

  • Multiple posting newcomer
  • *
  • Posts: 113
    • Code::Blocks EDU-Portable
Re: Doxygen plugin
« Reply #147 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.
« Last Edit: April 04, 2010, 09:15:25 am by codeur »

Offline codeur

  • Multiple posting newcomer
  • *
  • Posts: 113
    • Code::Blocks EDU-Portable
Re: Doxygen plugin
« Reply #148 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?
« Last Edit: April 04, 2010, 09:18:36 am by codeur »

Offline Cryogen

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


« Last Edit: April 07, 2010, 08:59:53 pm by Cryogen »