doxygen-develop — List for discussing new features, submitting patches, etc.

Re: [Doxygen-develop] Grouping Of Simple Sections

[Jake C. <co...@pp...>]

>>>>> "s" == smokingrope  <smo...@gm...> writes:

   s> I put together a feature request in bugzilla and have now submitted a patch
   s> which implements the desired functionality.

   s> http://bugzilla.gnome.org/show_bug.cgi?id=539333

   s> The idea was to allow certain paragraphs to be merged into a single
   s> paragraph before appearing int the final output formats created by doxygen.
   s> My reasoning behind doing this was to make a robust way for capturing the
   s> progression of events within a function. It just so happened that allowing
   s> existing paragraph commands such as note, return, author, etc... was very
   s> little trouble.

   s> This feature is similar to the addendum functionality described in the
   s> todo-list, however in the context of the paragraphs in a function, class or
   s> variable's documentation block.

   s> The patch has been generated against the doxygen 1.5.6 trunk, please let me
   s> know if there is anything i can do to help this feature into the codebase.

Sean,

I looked at your bugzilla entry and am confused about what your patch
does - although I think I'm quite interested.  

It always bothered me that the various sections of the documentation
appear strictly in the order that they were written.  Given multiple
developers, I cannot guarantee that they all do it the same way.  Does
your patch enforce the output ordering of those sections?

Also, how would someone use your new "merging" feature and what is its
point?  Why would you have the same section command multiple times for a
single block?  Or am I misunderstanding the point?

...Jake


-- 
Jake Colman
Director of Software Development
Principia Partners LLC
101 West Elm Street
Suite 620
Conshohocken, PA  19428
+1 (610) 755-9786
www.principiapartners.com

Re: [Doxygen-develop] JavaScript version of search.php for local file access

[Jake C. <co...@pp...>]

Roger,

First, I think this would be a great feature.  I have also faced the
problem where my Doxygen-generated files are not always served by a
server and, in that case, I cannot search.

I have implemented and submitted several features and fixes to Doxygen;
the process is very simple.  

1) Checkout the subversion source tree and build the system.
2) Implement and test your changes.
3) Create a patchset of your changes using 'diff' and tar them up into a
   file.
4) Create an enhancement request on Doxygen's bugzilla.  Edit that
   request and attach your patch indicating that you have implemented
   the solution.

Personally, I usual email Dimitri first to make sure that he would
consider accepting my patch before investing the time.  In some cases he
has given advice as to how he would like to see the solution implemented
and in one case he made it clear that he did not like what I was
proposing.

Good luck.

...Jake


>>>>> "RS" == Roger Spooner <ro...@pi...> writes:

   RS> Hi. I'm using Doxygen to write documents for several commercial SDKs 
   RS> which will be delivered as Zip files, and which need a search feature. 
   RS> Asking users to upload our files to an HTTP server so that they can run 
   RS> search.php is not ideal.

   RS> I think it would be possible to reimplement search.php using JavaScript 
   RS> for running locally in a browser. This would then need to be configured 
   RS> as an option in Doxygen to change what appears on each page, and what is 
   RS> copied to the output directory. I haven't edited the source of Doxygen 
   RS> before, so I have two questions.

   RS> 1. Does this JavaScript sound like a good and novel solution? Surely 
   RS> people have faced the problem of searching local Doxygen files before?

   RS> 2. Is there any advice around to guide me in editing the Doxygen code, 
   RS> so that it gets back into the main releases safely? ie schedule, patch 
   RS> files, coding style? I haven't started yet (but I have contributed to 
   RS> mscgen).

   RS> I would imagine using XMLHttpRequest to open search.idx and with partial 
   RS> HTTP GET commands. If this was used from a remote server, it would work, 
   RS> but would be slower.

   RS> Regards,
   RS> Roger

   RS> -------------------------------------------------------------------------
   RS> Check out the new SourceForge.net Marketplace.
   RS> It's the best place to buy or sell services for
   RS> just about anything Open Source.
   RS> http://sourceforge.net/services/buy/index.php

-- 
Jake Colman
Director of Software Development
Principia Partners LLC
101 West Elm Street
Suite 620
Conshohocken, PA  19428
+1 (610) 755-9786
www.principiapartners.com

[Doxygen-develop] Grouping Of Simple Sections

[SmokingRope <smo...@gm...>]

I put together a feature request in bugzilla and have now submitted a patch
which implements the desired functionality.

http://bugzilla.gnome.org/show_bug.cgi?id=539333

The idea was to allow certain paragraphs to be merged into a single
paragraph before appearing int the final output formats created by doxygen.
My reasoning behind doing this was to make a robust way for capturing the
progression of events within a function. It just so happened that allowing
existing paragraph commands such as note, return, author, etc... was very
little trouble.

This feature is similar to the addendum functionality described in the
todo-list, however in the context of the paragraphs in a function, class or
variable's documentation block.

The patch has been generated against the doxygen 1.5.6 trunk, please let me
know if there is anything i can do to help this feature into the codebase.

[Doxygen-develop] JavaScript version of search.php for local file access

[Roger S. <ro...@pi...>]

Hi. I'm using Doxygen to write documents for several commercial SDKs 
which will be delivered as Zip files, and which need a search feature. 
Asking users to upload our files to an HTTP server so that they can run 
search.php is not ideal.

I think it would be possible to reimplement search.php using JavaScript 
for running locally in a browser. This would then need to be configured 
as an option in Doxygen to change what appears on each page, and what is 
copied to the output directory. I haven't edited the source of Doxygen 
before, so I have two questions.

1. Does this JavaScript sound like a good and novel solution? Surely 
people have faced the problem of searching local Doxygen files before?

2. Is there any advice around to guide me in editing the Doxygen code, 
so that it gets back into the main releases safely? ie schedule, patch 
files, coding style? I haven't started yet (but I have contributed to 
mscgen).

I would imagine using XMLHttpRequest to open search.idx and with partial 
HTTP GET commands. If this was used from a remote server, it would work, 
but would be slower.

Regards,
Roger

Re: [Doxygen-develop] [Feature Request] @ReleaseNotes support in Doxygen

[SmokingRope <smo...@gm...>]

I have been considering a similar feature. I may even start development
soon. My goal was to track changes made to the source code. Most of it can
be accomplished with an alias.

ALIASES                 += changelog{1}="\xrefitem changes \"Change Made\"
\"Change Log\" <b>\1</b>: "

This alias creates an index page called changes consisting of all \changelog
commands encountered by doxygen. The first parameter is used as the heading
for that particular instance of the command. I used it as follows:

\changelog 06-16-2008 added a new feature

However it is not possible to sort with the elements, it would be ideal to
maintain a list of these elements in descending order based on date.

Your second requirement is very similar and provides a good second
perspective on what type of things might be needed in a sortable index.
Perhaps given a command like "\sortedxrefitem" you could use an alias
similar to the above to accomplish your own goals?

On Mon, Jun 16, 2008 at 2:44 AM, Stefan-Heiss <Ste...@in...>
wrote:

>
> I'm not sure if a ReleaseNotes feature in doxygen has been already
> proposed.
> I'm personally using Doxygen since quite a while and also for different
> projects. The tools is great. However, I'm somehow missing a possiblity to
> automatically generate my ReleaseNotes from Doxygen automatically.
> Therefore
> I post here...
>
> I propose following feature:
> - implement new keyword that allows entering release-notes distributed over
> a software project
> @RelNote [ReleaseNumber] [Type=<BugFix|Feature|Others>]
> [BugOrFeatureRequest-ID-Number]  {Description}
>
> ReleaseNumber: Release or Build number since when this bugfix/feature is
> implemented
> Type: Qualifier if this comment is a bugfix or FeatureRequest, etc...
> BugOrFeatureRequest-ID-Number: any ID number from bug-tracking system
> Description: Text, describing what has been fixed, added, etc...
>
> - All release notes shall be ending up in its own doxygen page. The page
> can
> be enabled, disabled just like the Todo or Test page.
> - Doxygen will order the output in the ReleasePage according to
> ReleaseNumber, for instance, so that all entries of the same ReleaseNumber
> are being grouped together.
>
>
> --
> View this message in context:
> http://www.nabble.com/-Feature-Request--%40ReleaseNotes-support-in-Doxygen-tp17771120p17771120.html
> Sent from the Doxygen - Development mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>

[Doxygen-develop] [Feature Request] @ReleaseNotes support in Doxygen

[Stefan-Heiss <Ste...@in...>]

I'm not sure if a ReleaseNotes feature in doxygen has been already proposed.
I'm personally using Doxygen since quite a while and also for different
projects. The tools is great. However, I'm somehow missing a possiblity to
automatically generate my ReleaseNotes from Doxygen automatically. Therefore
I post here...

I propose following feature:
- implement new keyword that allows entering release-notes distributed over
a software project
@RelNote [ReleaseNumber] [Type=<BugFix|Feature|Others>]
[BugOrFeatureRequest-ID-Number]  {Description}

ReleaseNumber: Release or Build number since when this bugfix/feature is
implemented
Type: Qualifier if this comment is a bugfix or FeatureRequest, etc...
BugOrFeatureRequest-ID-Number: any ID number from bug-tracking system
Description: Text, describing what has been fixed, added, etc...

- All release notes shall be ending up in its own doxygen page. The page can
be enabled, disabled just like the Todo or Test page.
- Doxygen will order the output in the ReleasePage according to
ReleaseNumber, for instance, so that all entries of the same ReleaseNumber
are being grouped together.


-- 
View this message in context: http://www.nabble.com/-Feature-Request--%40ReleaseNotes-support-in-Doxygen-tp17771120p17771120.html
Sent from the Doxygen - Development mailing list archive at Nabble.com.

Re: [Doxygen-develop] Embedding Doxygen Into A CMS

[SmokingRope <smo...@gm...>]

I have had some issues sending this patch through the mailing list and have
instead created an issue in the bugzilla database and attached the patch to
that issue.

http://bugzilla.gnome.org/show_bug.cgi?id=534391

Re: [Doxygen-develop] Not everyone c++ constructions has been parsed well

[Zebrik.0xFF <zeb...@gm...>]

Hmm, it seems it was DOT error

Re: [Doxygen-develop] Not everyone c++ constructions has been parsed well

[Zebrik.0xFF <zeb...@gm...>]

Marcus Lindblom ?????:
>
> >> is not valid C++ in template defs. use > > . (or was that a typo?)
>
> (It might be that VS 2005 swallows it, but it's not ok.)
>
> /Marcus
>
compiler output:
1> xxxx.h(18) : see declaration of 'iA'
1> xxxx.h(93) : see reference to class template instantiation 'C<T1,T2>' 
being compiled
1>yyyy.h(18) : error C2955: 'iA' : ****use of class template requires 
template argument list***

*So You think that it is a M$ feature ?
So how to do a inheritance from template classes iA and iB to template 
class C ??:
template <class T1,class T2>
class C
: public iA //like this?
, public iB //like this?
{...};

[Doxygen-develop] Not everyone c++ constructions has been parsed well

[Zebrik.0xFF <zeb...@gm...>]

Hello.
I have doxygen Version: 1.5.5 for Win32

It seems that, i can't get all reversed documentation using doxygen.

See example:

template <class T1,class T2>
class iA
{...};

template <class T>
class iB
{...};

template <class T1,class T2>
class C
  : public iA<T1,T2> //doxy error, but c++ eats
  , public iB<C<T1,T2>> //doxy error, but c++ eats
{...};

My MSVS.NET 2005 SP1 works well with it.
But doxy generate nothing about class C. Only abount .h and .cpp files 
containing it. No class diagramms, no relations.

My doxygen works well when my code looks like, but c++ reports errors:

template <class T1,class T2>
class iA
{...};

template <class T>
class iB
{...};

template <class T1,class T2>
class C
  : public iA //c++ error, but doxy eats
  , public iB //c++ error, but doxy eats
{...};

Question:
Is it doxygen bug, or i'am a dummy?

ps: sorry about my english localisation :)

[Doxygen-develop] DoxHPP : Doxygen Html Post Processor

[molecule <mol...@gm...>]

Hello developers!

I created for my own use a little tool to move html files in
hierarchical folders, and to update hyperlinks in html pages. This
tool creates 3 folders (html, pict, template) and the only file in the
root-folder is index.html (which was my target). The software is
written in C# so it's "windows only" and you need the Microsoft DotNet
Framework 2.0, sorry for that...

The tool was written very quickly, and it may appears as very ugly
(and very simple), but I GPLed it in the hope that it will be useful
to somebody. It may not work with every Doxygen-generated html folders
because I didn't test it with other code than mine.

Sourceforge project page :
https://sourceforge.net/projects/doxhpp/

Download page :
https://sourceforge.net/project/platformdownload.php?group_id=228144

Enjoy!

molecule

Re: [Doxygen-develop] Embedding Doxygen Into A CMS

[Dimitri V. H. <do...@gm...>]

On 15 mei 2008, at 07:48, SmokingRope wrote:

> I'm about 85% finished and just want to do some testing and update  
> the documentation before submitting a patch.

I'm looking forward to see what you made ;-)

> Is there a way to generate the file doc/config.doc from the  
> descriptions in 'config.l'? Or is it all just alphabetized; and  
> organized the same way, out of coincidence?

It is manually typed (and mostly indeed a copy of config.l).

Regards,
   Dimitri

[Doxygen-develop] What about doxywizard internationalization?

[Behzat E. <b3...@gm...>]

Hello everyone,

Could you make internationalization for Doxywizard ?

I think goog idea :-)

Best regards,
Behzat.

Re: [Doxygen-develop] Embedding Doxygen Into A CMS

[SmokingRope <smo...@gm...>]

I'm about 85% finished and just want to do some testing and update the
documentation before submitting a patch. Is there a way to generate the file
doc/config.doc from the descriptions in 'config.l'? Or is it all just
alphabetized; and organized the same way, out of coincidence?

Re: [Doxygen-develop] Namespace not properly recognized

[Jake C. <co...@pp...>]

>>>>> "TN" == Tim Niemueller <nie...@kb...> writes:

   TN> Hi Doxygen developers.
   TN> I have files like the following:

   TN> file.h:
   TN> namespace mynamespace {
   TN>   class MyClass {
   TN>    public:
   TN>     MyClass();
   TN>   }
   TN> }

   TN> file.cpp:
   TN> using namespace mynamespace;

   TN> /** @class MyClass <file.h>
   TN>  * My fancy class.
   TN>  */

   TN> /** Constructor. */
   TN> MyClass::MyClass()
   TN> {
   TN> }

   TN> This seems to be valid C++ and compiles properly (tested with GCC 4.1
   TN> and 4.3 on Fedora 8 and 9). However, if I try to run doxygen
   TN> (doxygen-1.5.5-2.fc8) on this it will complain:
   TN> Warning: Compound mynamespace::MyClass is not documented.

   TN> What I would expect is that it collects the "using namespace" clauses
   TN> and prepends these namespaces to the class names to test for matching
   TN> documentation. Can someone point me to the relevant lines in the code to
   TN> have a closer look or knows a solution already?

   TN> Regards from Aachen,
   TN> 	Tim

The safest way to do this, in my opinion, is to have class documentation
immediately preceded the class declaration in the header file.  This
guarantees that Doxygen will find it correctly.  Otherwise, doing it the
way you did it with the class documentation in the .cc file, you must
fully qualify the name of the class in order for Doxygen to match the
documentation with the class.

-- 
Jake Colman
Director of Software Development
Principia Partners LLC
101 West Elm Street
Suite 620
Conshohocken, PA  19428
+1 (610) 755-9786
www.principiapartners.com

[Doxygen-develop] Embedding Doxygen Into A CMS

[SmokingRope <smo...@gm...>]

I want to put together a patch for allowing doxygen's html output to be
embedded into a CMS. I'm testing with a very primitive php webpage; however
being familiar with a few real CMS systems, my belief is that this
implementation is general enough to work for most. My plan is to allow users
to specify a prefix, and doxygen will generate paths which use this prefix
when generating links to files. I am hoping to make something suitable for
inclusion in the doxygen code base, and your thoughts would be welcome.

Goals

   - All html elements which are outside of the body tag, including the body
   tag itself should be removed.
   - The links which are generated currently use relative paths, however may
   not function properly considering a CMS frontend which includes the doxygen
   pages into an existing template. The link generation needs to be updated to
   prefix links with a customizeable link header
   - Filenames, including images, which are generally specified as relative
   paths need to be specified in a different way when embedded in a parent web
   page. A simple implementation would use the same format as above, however it
   is altogether possible that a different linking format could be used to
   allow certain files to be provided by a CMS in a more robust way (say
   placing the logo in a DB). It might be best to define one or more distinct
   prefix formats to use as replacements for non html file types.
   - It may be desirable to perform some amount of post-processing on the
   generated links. The major need for post-processing stems from the special
   semantics involved in the standard http get request, and escaping certain
   characters might be necessary. This feature can be postponed until the
   implementation is done however, and may be unnecessary.
   - Elements which i have identified as needing attention : <A>, <IMG>,
   <AREA>, <MAP>

Questions?

Other html elements which need consideration?

Is there any other functionality needed which i have not thought of?

Should configuration settings be in a seperate section, much like the search
engine feature, or defined inline with the other HTML generator options?
Timeline

This isn't a very complicated feature, and i only expect to need a week or
so to get it right. There are also a lot of templating/style features which
won't be addressed, but it does seem to be a precursor to more customizable
and dynamic html output.

Following this it would also be useful to update the html generator with
better css names, specifically to avoid conflicts with the stylesheets of an
existing CMS.

[Doxygen-develop] PATCH: Cygwin port

[Warren Y. <wa...@et...>]

The following one-line change allows the current version of Doxygen to 
build on Cygwin.


--- origsrc/doxygen-1.5.5/tmake/lib/linux-g++/tmake.conf
+++ src/doxygen-1.5.5/tmake/lib/linux-g++/tmake.conf
@@ -42,7 +42,7 @@
  TMAKE_LFLAGS_SHLIB = -shared
  TMAKE_LFLAGS_SONAME    = -Wl,-soname,

-TMAKE_LIBS     =
+TMAKE_LIBS     = -liconv
  TMAKE_LIBS_X11     = -lXext -lX11 -lm
  TMAKE_LIBS_X11SM   = -lICE -lSM
  TMAKE_LIBS_QT      = -lqt


It shouldn't be applied to the top-level Doxygen sources, because 
libiconv doesn't actually exist for Linux.  (iconv() is in glibc.  It's 
separate on Cygwin because Cygwin uses a different Standard C library, 
which doesn't include iconv().)

Instead, we need a 'cygwin-g++' build configuration.  Such a thing 
already exists in the top-level tmake distribution.  It seems to be 
identical to linux-g++, currently, so essentially the same patch applies.

I don't think this patch needs to be applied to tmake itself, since not 
all tmake users will need this.  Besides, tmake seems moribund.

[Doxygen-develop] Namespace not properly recognized

[Tim N. <nie...@kb...>]

Hi Doxygen developers.

I have files like the following:

file.h:
namespace mynamespace {
  class MyClass {
   public:
    MyClass();
  }
}

file.cpp:
using namespace mynamespace;

/** @class MyClass <file.h>
 * My fancy class.
 */

/** Constructor. */
MyClass::MyClass()
{
}


This seems to be valid C++ and compiles properly (tested with GCC 4.1
and 4.3 on Fedora 8 and 9). However, if I try to run doxygen
(doxygen-1.5.5-2.fc8) on this it will complain:
Warning: Compound mynamespace::MyClass is not documented.

What I would expect is that it collects the "using namespace" clauses
and prepends these namespaces to the class names to test for matching
documentation. Can someone point me to the relevant lines in the code to
have a closer look or knows a solution already?

Regards from Aachen,
	Tim

-- 
Tim Niemueller                      KBSG - Knowledge-Based Systems Group
========================================================================
AllemaniACs RoboCup Team                          RWTH Aachen University
http://robocup.rwth-aachen.de                            Ahornstrasse 55
http://www.kbsg.rwth-aachen.de                            D-52056 Aachen

Re: [Doxygen-develop] spec file issues in 1.5.5

[Dimitri V. H. <do...@gm...>]

On 21 apr 2008, at 02:11, Kenneth Porter wrote:

> --On Sunday, April 20, 2008 10:05 AM +0200 Dimitri Van Heesch
> <do...@gm...> wrote:
>
>> Thanks, I'll include it in the next subversion update.
>
> In the RPM section of download.html on the website, you could add:
>
> To build your own package from the distribution tarball or from a
> Subversion checkout:
>
> \code
> ./configure
> make rpm
> \endcode
>
> or, to add a doxywizard sub-package:
>
> \code
> ./configure --with-doxywizard
> make rpm
> \endcode

Thanks, I'll do that.

Regards,
   Dimitri

Re: [Doxygen-develop] spec file issues in 1.5.5

[Kenneth P. <sh...@se...>]

--On Sunday, April 20, 2008 10:05 AM +0200 Dimitri Van Heesch 
<do...@gm...> wrote:

> Thanks, I'll include it in the next subversion update.

In the RPM section of download.html on the website, you could add:

To build your own package from the distribution tarball or from a 
Subversion checkout:

\code
./configure
make rpm
\endcode

or, to add a doxywizard sub-package:

\code
./configure --with-doxywizard
make rpm
\endcode

Re: [Doxygen-develop] spec file issues in 1.5.5

[Dimitri V. H. <do...@gm...>]

On 18 apr 2008, at 10:04, Kenneth Porter wrote:

> A more comprehensive patch that eliminates the extra spec  
> file.<doxygen-spec.patch>

Thanks, I'll include it in the next subversion update.

Regards,
   Dimitri

Re: [Doxygen-develop] spec file issues in 1.5.5

[Kenneth P. <sh...@se...>]

BTW, here's some documentation on RPM conditionals:

<http://wraptastic.org/apidocs/html/conditionalbuilds.html>

Re: [Doxygen-develop] spec file issues in 1.5.5

[Kenneth P. <sh...@se...>]

A more comprehensive patch that eliminates the extra spec file.

Re: [Doxygen-develop] spec file issues in 1.5.5

[Kenneth P. <sh...@se...>]

--On Wednesday, April 16, 2008 10:13 PM +0200 Dimitri Van Heesch 
<do...@gm...> wrote:

> The configure script makes the .spec file from the .spec.in
> It also puts in the version number.

Ok, and it looks like there are two .spec.in files, with and without 
doxywizard, otherwise identical. There's RPM macro syntax to conditionally 
include part of a spec file, so I think those can be merged. I'll look at 
that.

Re: [Doxygen-develop] spec file issues in 1.5.5

[Kenneth P. <sh...@se...>]

--On Tuesday, April 15, 2008 5:45 PM -0700 Kenneth Porter 
<sh...@se...> wrote:

> /usr/man/man1/doxywizard.1.gz is missing from %files.

Addressed with attached patch. man page for doxywizard should be installed 
by doxywizard Makefile, not main Makefile.

(Patch generated with "svn diff".)