Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Doxygen plugin
Cryogen:
--- Quote from: codeur on April 04, 2010, 02:10:02 am ---
--- Quote from: Cryogen on April 03, 2010, 07:51:50 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?
--- End quote ---
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?
--- End quote ---
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.
codeur:
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.
Cryogen:
Hey Codeur,
--- Quote from: codeur on April 07, 2010, 01:01:00 am ---Thanks for replying to my long email.
--- End quote ---
Not at all, old chap. 8)
--- Quote from: codeur on April 07, 2010, 01:01:00 am ---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.
--- End quote ---
That's because I was. Yes, you're right. ;-)
--- Quote from: codeur on April 07, 2010, 01:01:00 am ---Yes, I am the guilty party putting together CB EDU-Portable.
--- End quote ---
Nice one.
--- Quote from: codeur on April 07, 2010, 01:01:00 am ---Can you please edit that post of yours and obfuscate the EDU-Portable URL... (whole bunch of good reasons)
--- End quote ---
Sure thing. Done.
--- Quote from: codeur on April 07, 2010, 01:01:00 am ---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.
--- End quote ---
Even better. :D
--- Quote from: codeur on April 07, 2010, 01:01:00 am ---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.
--- End quote ---
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.
--- Quote from: codeur on April 07, 2010, 01:01:00 am ---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 ...
--- End quote ---
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. ;-)
--- Quote from: codeur on April 07, 2010, 01:01:00 am ---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.
--- End quote ---
You're welcome, and thanks. More power to you for teaching things the right way.
codeur:
--- Quote from: Cryogen on April 07, 2010, 08:58:42 pm ---
--- Quote from: codeur on April 07, 2010, 01:01:00 am ---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 ...
--- End quote ---
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. ;-)
--- End quote ---
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:
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. :?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version