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

Re: [Doxygen-develop] strategies for XHTML support

[<do...@ke...>]

On Wed, Mar 05, 2008 at 03:12:49PM +0100, Francesco Montorsi wrote:

> Francesco Montorsi ha scritto:
> > In conclusion: I need a pause and some help to complete this patch :)
> > 
> > What's your (doxygen team) interest toward XHTML?
> > Isn't it one of your priorities?
> so, there's no interest in XHTML development?
> Noone willing to help me?

I'm willing to help.  I'm very behind on the internals of Doxygen,
though, so I don't know how much help I can be.

What do you need other people to help with?

Chris C

Re: [Doxygen-develop] strategies for XHTML support

[Francesco M. <f18...@ya...>]

Hi,

Francesco Montorsi ha scritto:
> In conclusion: I need a pause and some help to complete this patch :)
> 
> What's your (doxygen team) interest toward XHTML?
> Isn't it one of your priorities?
so, there's no interest in XHTML development?
Noone willing to help me?


That's a pity...
Francesco

[Doxygen-develop] Google Summer of Code 2008...

[Francesco M. <f18...@ya...>]

Hi,
   I don't know if doxygen developers are aware of the Google Summer of 
Code project. More info are here:

  http://code.google.com/soc/2008/

I suggest to Doxygen devs to register as mentoring organization:

  http://code.google.com/soc/2008/org_signup.html

and then propose to students projects which help the development of 
Doxygen. One could be the XHTML support ;)

I've also seen there's a long TODO list on the website; each of those 
items (say those with difficulty <= 7) would be good GSoC projects IMHO.

GSoC is doing a lot of Good things in Open Source; it would be a pity if 
a project widely used like Doxygen didn't take advantage of this 
possibility.

Francesco


PS: I've partecipated twice as student, if can give more details to 
interested peoples...

[Doxygen-develop] documentation of member classes defined outside class

[Robbie G. <ro...@m8...>]

Hi All,
  If i have code where member classes are defined outside their
containing class, like

/** Class X doco */
{
  /** Class Y doco */
  class Y;
};

class X::Y
{
};

then, afaics, doxygen doesn't pick up the doco at the declaration of
class Y - one needs to do it at the definition viz:

{
  /** Class Y doco */
  class Y;
};

/** Class X doco */
class X::Y
{
};

It seems that the versions i'm looking at are discarded as forward
declarations, around line 4306 of scanner.l (1.5.5 sources). I can
easily add a warning so i can pick up the cases where we do this and
move the documentation to the definition.

    if (!current->doc.isEmpty() || !current->brief.isEmpty())
    {
        warn(yyFileName, yyLineNr, "Warning: Ignoring documentation on
forward declaration");
    }

just before current->reset(), but i'd be interested in pointers about
the "right" way to arrange for this documentation to just get merged -
i.e. to effectively fake an @class yytext at that point. Is it
legitimate to just do what handleClass (in commentscan.l) would have
done, that is, something like

    current->section = Entry::CLASSDOC_SEC;
    current->name = yytext;
    current->name.remove(current->name.length() - 1, 1);
    prependScope();
    newEntry();

or am i missing a subtlety here ? I realise it also incorporates
documentation for forward declarations, but this doesn't seem terrible
afaics.

I should add i've tried both of these (i.e. warning, and faking the
@class block as described), and they appear to work - i just want to
check i'm not missing something important.  If its all good, i'll
clean it up and send patches.

If both declaration and definition are given, these are merged. I
wonder if its possible to warn about this, as if you're not aware its
happening, you tend to get suboptimal documentation (with things
repeated, etc).

 - robbie

Re: [Doxygen-develop] \li2, \li3 revisited

[Matthew W. <mw_...@us...>]

Matthew Woehlke wrote:
> Dimitri Van Heesch wrote:
>>> Dmitri, can we revisit this? I'm happy to see about getting it cleaned
>>> up against current svn if you'd be willing to accept it.
>>
>> Yes, I'm interested in a patch for this if it provides a solution to  
>> make
>> \param like commands.
> 
> Here's the old patch updated against svn r614. It built but I haven't 
> tried to run it yet. Please let me know if this looks right, also if 
> there are any changes that need to be made for this to be accepted.

bump?

(patch available at http://permalink.gmane.org/gmane.text.doxygen.devel/894)

-- 
Matthew
There are lies, and damn lies... and then there is marketing
   -- a coworker

Re: [Doxygen-develop] strategies for XHTML support

[James D. <jam...@gm...>]

On Sun, Mar 2, 2008 at 1:47 AM, Francesco Montorsi
<f18...@ya...> wrote:

(lots of good stuff)

>  3) remove deprecated HTML4 attributes (compact, nowrap, some align, etc)
>   from htmlgen.cpp and htmldocvisitor.cpp; turn empty tags from e.g.
>  <br> to <br/>; rename 'name' attribute to 'id' attribute

One trivial point: while "<br/>" is correct, so is "<br />" (with an
extra space before
the closing "/>") and last time I checked (converting a small website from HTML
to xhtml) was supported by a wider range of HTML processors.

-- James

Re: [Doxygen-develop] strategies for XHTML support

[Francesco M. <f18...@ya...>]

do...@ke... ha scritto:
> On Sun, Mar 02, 2008 at 04:00:10PM +0100, Francesco Montorsi wrote:
> 
>> I think that the postprocessing of the HTML output will be much 
>> simplified if doxygen starts outputting XHTML instead of HTML4, which is 
>> not valid XML.
> 
> Certainly it should be easier to parse if it is valid XML, if they were
> starting from scratch.  The problem is wiht existing translators
> expecting the non-valid format.
this is not IMO a good reason to continue generating HTML4 instead XHTML...


>> Companies doing this kind of postprocessing will eventually need some 
>> changes to their scripts but this is probably true after all doxygen 
>> releases since the structure of the generated HTML is not granted to 
>> remain the same and in fact, most times it changes from a release to 
>> another.
> 
> I wonder how much it does.  I don't know, I'm not directly in touch with
> those places which do that sort of transformation.
I'm not, too so I don't know for sure...


>> Doxygen cannot continue to produce HTML4 forever (*)!
>> Technologies are evolving and the switch from HTML4 to XHTML I think is 
>> worth some troubles/regressions.
>>
>> It's just that sometimes I think that all doxygen sources should be 
>> entirely rewritten and reorganized (with more comments!!) in order to 
>> fix all of these errors.
> 
> I have had the feeling that what it should be producing is just XML, and
> then have back-ends which produce whatever other formats people want
> (XSLT could do most of them).
does any backend based on the doxygen XML output exist?
I fear that using just XSLT it's going to be very difficult to generate 
something which resembles the current doxygen HTML output.

> "Rewrite from scratch" is my mantra with almost everything (especially
> my own code), but the time and effort to do that tends to be
> prohibitive.  Especially when what's there is 'almost' right.
however I think that with the current startXXX()/endXXX() paradigm it's 
too easy to make errors and forget e.g. a closing tag somewhere.

If doxygen used a more object-oriented approach:

   OutputNode *n = outputList->appendRootNode();
   OutputNode *p = n->appendParagraph();
   p->writeClassMemberList();
   ...

   outputList->dumpOutputTree();

it would be impossible to forget closing tags (each output node would 
write for HTML <myself>[children nodes]</myself>) or to generate invalid 
trees. Obviously this approach works well only for tree-structured docs 
like (X)HTML. I fear that Doxygen (at least when it was started) placed 
too emphasis on the generation of other formats like man or latex.
now HTML is by far the most important format it generates and if the 
*def.cpp files were coded in a way like that mentioned above, the 
generated HTML would be of higher quality with less programming efforts 
(shorter and more readable code).


>> (*) = I also strongly doubt it produces VALID html4 now; testing it is 
>> not easy as doing an HTML4 validation test is much more difficult than 
>> doing an XHTML validation test and requires for me to upload file by 
>> file the generated output to the w3c validator.
> 
> Don't they do a stand-alone validator?  Most people do want to validate
> entire sites or at least sets of pages.
there's no free command-line validator for HTML4 AFAIK.
w3c publishes the sources of his validator but you can install it 
locally only setting up an apache installation. And anyway you still 
have to validate each file by hand.

Not feasible for projects with big documentation file sets.

XHTML is way easier to validate. In the patch I proposed I attached an 
archive which contains a simple script which allows to validate from 
command-line an arbitrary number of HTML files and nicely reports all 
erors in a log file.

Francesco

Re: [Doxygen-develop] strategies for XHTML support

[<do...@ke...>]

On Sun, Mar 02, 2008 at 04:00:10PM +0100, Francesco Montorsi wrote:

> I think that the postprocessing of the HTML output will be much 
> simplified if doxygen starts outputting XHTML instead of HTML4, which is 
> not valid XML.

Certainly it should be easier to parse if it is valid XML, if they were
starting from scratch.  The problem is wiht existing translators
expecting the non-valid format.

> Companies doing this kind of postprocessing will eventually need some 
> changes to their scripts but this is probably true after all doxygen 
> releases since the structure of the generated HTML is not granted to 
> remain the same and in fact, most times it changes from a release to 
> another.

I wonder how much it does.  I don't know, I'm not directly in touch with
those places which do that sort of transformation.

> Doxygen cannot continue to produce HTML4 forever (*)!
> Technologies are evolving and the switch from HTML4 to XHTML I think is 
> worth some troubles/regressions.
> 
> It's just that sometimes I think that all doxygen sources should be 
> entirely rewritten and reorganized (with more comments!!) in order to 
> fix all of these errors.

I have had the feeling that what it should be producing is just XML, and
then have back-ends which produce whatever other formats people want
(XSLT could do most of them).

"Rewrite from scratch" is my mantra with almost everything (especially
my own code), but the time and effort to do that tends to be
prohibitive.  Especially when what's there is 'almost' right.

> (*) = I also strongly doubt it produces VALID html4 now; testing it is 
> not easy as doing an HTML4 validation test is much more difficult than 
> doing an XHTML validation test and requires for me to upload file by 
> file the generated output to the w3c validator.

Don't they do a stand-alone validator?  Most people do want to validate
entire sites or at least sets of pages.

Chris C

Re: [Doxygen-develop] strategies for XHTML support

[Francesco M. <f18...@ya...>]

do...@ke... ha scritto:
> On Sun, Mar 02, 2008 at 02:00:35PM +0100, Francesco Montorsi wrote:
> 
>> btw if you are not interested to reach 100% well-formness in a single 
>> patch, then the one I've attached seems to work quite well in terms of 
>> output rendering (i.e. there are no big differences to the std doxygen 
>> HTML4, just some spacing differences). I'm not sure however it 
>> well-behaves respect the other output formats...
> 
> It might also break some post-processing some places use.  I know
> several companies which post-process Doxygen output to create their own
> documentation, but I don't know how robust their processing is.
I think that the postprocessing of the HTML output will be much 
simplified if doxygen starts outputting XHTML instead of HTML4, which is 
not valid XML.
Companies doing this kind of postprocessing will eventually need some 
changes to their scripts but this is probably true after all doxygen 
releases since the structure of the generated HTML is not granted to 
remain the same and in fact, most times it changes from a release to 
another.

>> (*) = I wanted to enable XHTML output in order to use XSLT stylesheets 
>> over it, instead of doing it over the doxygen XML output.
> 
> Have you tried processing it with the W3C 'tidy' program?  That usually
> does a pretty good job of producing XHTML from HTML with close tags
> missing (what lynx calls "tag soup"), and will produce XML as well as
> XHTML output.  (Doing it on the number of files Doxygen creates is a
> pain and slow, though, and you need to disable its comments about how
> 'bad' the original is.)
tidy does a good job but I think it's a "dirty" solution: its output is 
not granted to be the "right" one (it repairs the HTML as best as it can 
but it's still a machine and can't look at the context to understand 
what's the right fix) and may generate rendering artefacts (caused by 
syntatically correct but semanthically wrong markup).

It's true that cleaning with 'tidy' the generated XHTML of the doxygen 
samples (I'm testing it with my patch applied) it shrinks the validation 
  errors from about 700 to about 30 (great!!) but still those 30 needs 
human revision. In the bigger project which I'm trying to convert to 
Doxygen (FYI it's wxWidgets), there would be still hundreds of errors to 
handle by hand. Not feasible.

It's the doxygen output which should be correct without any further 
processing.

Doxygen cannot continue to produce HTML4 forever (*)!
Technologies are evolving and the switch from HTML4 to XHTML I think is 
worth some troubles/regressions.

It's just that sometimes I think that all doxygen sources should be 
entirely rewritten and reorganized (with more comments!!) in order to 
fix all of these errors.

In conclusion: I need a pause and some help to complete this patch :)

What's your (doxygen team) interest toward XHTML?
Isn't it one of your priorities?

Francesco



(*) = I also strongly doubt it produces VALID html4 now; testing it is 
not easy as doing an HTML4 validation test is much more difficult than 
doing an XHTML validation test and requires for me to upload file by 
file the generated output to the w3c validator.

Re: [Doxygen-develop] strategies for XHTML support

[<do...@ke...>]

On Sun, Mar 02, 2008 at 02:00:35PM +0100, Francesco Montorsi wrote:

> btw if you are not interested to reach 100% well-formness in a single 
> patch, then the one I've attached seems to work quite well in terms of 
> output rendering (i.e. there are no big differences to the std doxygen 
> HTML4, just some spacing differences). I'm not sure however it 
> well-behaves respect the other output formats...

It might also break some post-processing some places use.  I know
several companies which post-process Doxygen output to create their own
documentation, but I don't know how robust their processing is.

> (*) = I wanted to enable XHTML output in order to use XSLT stylesheets 
> over it, instead of doing it over the doxygen XML output.

Have you tried processing it with the W3C 'tidy' program?  That usually
does a pretty good job of producing XHTML from HTML with close tags
missing (what lynx calls "tag soup"), and will produce XML as well as
XHTML output.  (Doing it on the number of files Doxygen creates is a
pain and slow, though, and you need to disable its comments about how
'bad' the original is.)

Chris C

Re: [Doxygen-develop] strategies for XHTML support

[Francesco M. <f18...@ya...>]

Francesco Montorsi ha scritto:
> I attach the _preview_ version of a patch doing these 5 things to show 
> you better what I mean...
I'm a bit blocked by the table generation code -- I really have troubles 
to understand what it does and why. I must say that all the output 
generation code is quite messy.

I've attached a patch with the results I obtained so far here:

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

I hope to be able to complete it in future but I've realized that in the 
near term I must seek another solution to my problems (*).

btw if you are not interested to reach 100% well-formness in a single 
patch, then the one I've attached seems to work quite well in terms of 
output rendering (i.e. there are no big differences to the std doxygen 
HTML4, just some spacing differences). I'm not sure however it 
well-behaves respect the other output formats...

Francesco


(*) = I wanted to enable XHTML output in order to use XSLT stylesheets 
over it, instead of doing it over the doxygen XML output.

[Doxygen-develop] strategies for XHTML support

[Francesco M. <f18...@ya...>]

Hi,
   before making a kilometric patch I'd like to discuss the changes I 
think are necessary for XHTML support:

1) split BaseOutputDocInterface::writeListItem into two functions: 
startItemListItem, endItemListItem, which allow to put also the 
necessary </li> correctly everywhere required.

2) split BaseOutputDocInterface::writeDescItem into two functions: 
startDescForItem, endDescForItem, which allow to put also the necessary 
</dd> correctly everywhere required.

3) remove deprecated HTML4 attributes (compact, nowrap, some align, etc) 
  from htmlgen.cpp and htmldocvisitor.cpp; turn empty tags from e.g. 
<br> to <br/>; rename 'name' attribute to 'id' attribute

4) change MemberDef::setAnchor to generate an anchor ID which always 
starts with a non-numeric character (as required by 'id' attribute); 
I've done this just prefixing the MD5 with 'a'

5) most tedious one: couple _every_ startParagraph/newParagraph call to 
a endParagraph one

I attach the _preview_ version of a patch doing these 5 things to show 
you better what I mean...

Please tell me if you think I'm doing something wrong: I hate do useless 
work :)

Francesco

Re: [Doxygen-develop] difference between startParagraph() and newParagraph()

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

On 2 mrt 2008, at 00:27, Francesco Montorsi wrote:

> Hi,
>   what's the difference between
>
>  BaseOutputDocInterface::startParagraph
>
>  and
>
>  BaseOutputDocInterface::newParagraph ?
>
> I'd like to understand it to fix the <p> disposal which is the main
> obstacle to correct XHTML generation...

The newParagraph was added before startParagraph, at a time
I did not saw the need for a </p> marker.

Later on startParagraph()
and endParagraph() were added, but the code still has calls to
newParagraph() as well, so these need to be replaced.

Also note the TODO in HtmlDocVisitor::visitPre(DocPara *) in  
htmldocvisitor.cpp

Regards,
   Dimitri

[Doxygen-develop] difference between startParagraph() and newParagraph()

[Francesco M. <f18...@ya...>]

Hi,
   what's the difference between

  BaseOutputDocInterface::startParagraph

  and

  BaseOutputDocInterface::newParagraph ?

I'd like to understand it to fix the <p> disposal which is the main 
obstacle to correct XHTML generation...

Thanks,
Francesco

Re: [Doxygen-develop] XHTML output format

[Francesco M. <f18...@ya...>]

Dimitri Van Heesch ha scritto:
> On 1 mrt 2008, at 16:34, Francesco Montorsi wrote:
> 
>> Hi,
>>    I'm looking at doxygen sources as I'd be interested into adding
>> XHTML output format capabilities...
>>
>> looking at htmlgen.cpp and htmlgen.h I see that apparently only a  
>> small
>> number of changes there should allow the generation of XHTML compliant
>> output files... isn't it?
>>
>> Would you accept a patch which modifies the HtmlGenerator class to
>> output either HTML 4.01 or XHTML 1.1 based on a new configuration
>> setting HTML_OUTPUT_VERSION = HTML4|XHTML1.1 ?
> 
> Yes, I would accept such a patch. If you do not need to make  
> concessions to
> the way the resulting pages look then it does not even have to be an  
> option for me.
ok; then I'm making a patch which simply changes the current output from 
HTML4 to XHTML 1.0 strict (actually I realized XHTML 1.1 is still not a 
recommendation but a working draft / proposed recommendation).

I'm quite sure the output look won't change in any sensible way.


>> One annoying thing I'm trying to fix is that, at least for the HTML
>> pages generated in response to @page commands, <p> start tags are
>> correctly generated but not their relative </p> close tags...
> 
> Indeed, that is probably the biggest issue.
I've partially sorted it out...

Francesco

Re: [Doxygen-develop] XHTML output format

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

On 1 mrt 2008, at 16:34, Francesco Montorsi wrote:

> Hi,
>    I'm looking at doxygen sources as I'd be interested into adding
> XHTML output format capabilities...
>
> looking at htmlgen.cpp and htmlgen.h I see that apparently only a  
> small
> number of changes there should allow the generation of XHTML compliant
> output files... isn't it?
>
> Would you accept a patch which modifies the HtmlGenerator class to
> output either HTML 4.01 or XHTML 1.1 based on a new configuration
> setting HTML_OUTPUT_VERSION = HTML4|XHTML1.1 ?

Yes, I would accept such a patch. If you do not need to make  
concessions to
the way the resulting pages look then it does not even have to be an  
option for me.

> One annoying thing I'm trying to fix is that, at least for the HTML
> pages generated in response to @page commands, <p> start tags are
> correctly generated but not their relative </p> close tags...

Indeed, that is probably the biggest issue.

Regards,
   Dimitri

[Doxygen-develop] XHTML output format

[Francesco M. <f18...@ya...>]

Hi,
    I'm looking at doxygen sources as I'd be interested into adding 
XHTML output format capabilities...

looking at htmlgen.cpp and htmlgen.h I see that apparently only a small 
number of changes there should allow the generation of XHTML compliant 
output files... isn't it?

Would you accept a patch which modifies the HtmlGenerator class to 
output either HTML 4.01 or XHTML 1.1 based on a new configuration 
setting HTML_OUTPUT_VERSION = HTML4|XHTML1.1 ?

One annoying thing I'm trying to fix is that, at least for the HTML 
pages generated in response to @page commands, <p> start tags are 
correctly generated but not their relative </p> close tags...

Francesco

[Doxygen-develop] Back-end for Igor Pro code?

[Florin <fl...@bo...>]

Hello everybody!

I'd like to use doxygen to generate documentation from scripting
code for the Igor Pro data analysis tool (http://www.wavemetrics.com/).

I put a sample Igor Pro file at
http://www.physik.uni-wuerzburg.de/~bflorin/00Nuber.ipf
so you can get an impression about how Igor Pro scripting code looks
like.

The sample code at the URL above has comments which use doxygen-like
keywords to emphasize parameters, function briefs etc because I
originally intended to write some python scripts to do some
very rudimentary parsing & doc generating, but then I figured than since
doxygen does such a good job in generating all kinds of documentation
outputs, it might be a good idea to somehow teach doxygen how to read
Igor Pro files (.IPF) instead of re-inventing the wheel by writing a
code documentation program from scratch.

So, my question is, what would be the best approach to teach doxygen
how to read .IPF files? Where should I start?

About my skills: I have quite a lot of experience with like C/C++ and
some rudimentary experience with python. I'm average on using regular
expressions (mostly gained through shell scripting and sed parsing)...

best regards,
florin.

[Doxygen-develop] Pages directly follow the mainpage; possibility to enable old style neaded

[<Eck...@t-...>]

Hello Doxygen Developers.


If I take a look to the change-lock of doxygen I find the following
Information:


Doxygen Release 1.5.5
(release date 10-02-2008)
Changes:
Pages created with @page are now chapters in the LaTeX and RTF output
and treeviews, and directly follow the mainpage. ...


And that's exactly what doxygen 1.5.5 does. So this is not a bug this is
a feature. But without a possibility to disable it, this is a bad
feature. There are good reasons to offer a possibility for placing pages
as top-chapters. But if you have implemented a documentation-process
where normal pages are used to hold attached information as appendix the
new doxygen-release is not useable anymore. Some of us have now
"thousands" of single pages on the top-level of the tree view or
chapter-hierarchy, which contain only additional information. As we say
in Germany "Because the trees you are not able to see the forest
anymore." Before release 1.5.5 these pages where hidden under the
book/chapter "related pages". 


We need urgently a possibility to restore the old style with the
chapter/tree-level "related pages" via the configuration of doxygen,
something like:

            USE_RELEATED_PAGES=YES/NO


For the future, I suppose also the implementation of a command

                          \inpage <pagename style="margin:0px;"> 

similar to the command \ingroup. 

Currently the only way I know to add a page as sub-page is the command
\subpage. But this is used in the definition of the super-page that
holds the link to the sub-page. This means you have to work on 2 places.
You write your page on one place of the documentation and than you have
to add the command \subpage on another place of the documentation. If
you have a small project and you work alone this may be acceptable. But
if you work in a great project as a member of a team this means that 2
persons have to write the documentation of on thing. One person writes
the documentation itself and than he calls the one who is responsible
for the backbone of the documentation because this person has to add the
new page as sub-page. 


Kind Regards,

               Eckard Klotz.

Re: [Doxygen-develop] \li2, \li3 revisited

[Matthew W. <mw_...@us...>]

Dimitri Van Heesch wrote:
>> Dmitri, can we revisit this? I'm happy to see about getting it cleaned
>> up against current svn if you'd be willing to accept it.
> 
> Yes, I'm interested in a patch for this if it provides a solution to  
> make
> \param like commands.

Here's the old patch updated against svn r614. It built but I haven't 
tried to run it yet. Please let me know if this looks right, also if 
there are any changes that need to be made for this to be accepted.

-- 
Matthew
"Doggy!" -- Robots from Freefall (http://freefall.purrsia.com)

Re: [Doxygen-develop] New Release is Online Moritz 1.0.03

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

On 24 feb 2008, at 12:06, Eck...@t-... wrote:
> Unfortunately there is still a problem in the newest version (1.5.5)  
> of Doxygen reported as:
>
>              "Bug 504025 – preprocessor-directive doxygen is not  
> able to recognize".
>
> Since Moritz uses Doxygen as pre-parser, this has the effect that  
> some compiler-switches may not be shown as they should. I reported  
> this bug last year in december, because it is the corse of some  
> discusions and bug-reorts around the using of Moritz. But since than  
> the status of this bug is still "UNCONFIRMED".  What did I make wrong?

The source code parser does not do preprocessing at the moment, so  
that is why your example does not work correctly.
I'm aware of the problem, but haven't gotten around to fix it.

Regards,
   Dimitri

[Doxygen-develop] New Release is Online Moritz 1.0.03

[<Eck...@t-...>]

<font style="font-family: arial,helvetica,sans-serif;" size="2">Hello
Everybody.<br />
 <br />
 Since yesterday a new release of moritz the nassi-shneiderman generator
for doxygen is available under
https://sourceforge.net/projects/moritz/.<br />
 <br />As new features the main-diagrams of a function contains links to
excluded sub-diagrams and Moritz generates an index-file in the
output-directory, that helps to find the diagram of a special
function. <br />
 <br />
After more than 3 years of development the newest release of Moritz has
got the mayor version-number 1. This means it is the first real release
and not only a release-candidate. The project has now the status
stable.  <br />
 <br />
Moritz is stable now, really stable? <br />
Well try it out and tell me. You may use the forum or the bug-tracker
if you have questions, some additional ideas or if you found bugs. <br
/><br />
Unfortunately there is still a problem in the newest version (1.5.5) of
Doxygen reported as: <br /><br />            
&quot;Bug 504025 – preprocessor-directive doxygen is not able to
recognize&quot;. <br /><br />Since Moritz uses Doxygen as pre-parser,
this has the effect that some
compiler-switches may not be shown as they should. I reported this bug
last year in december, because it is the corse of some discusions and
bug-reorts around the using of Moritz. But since than the status of this
bug is still &quot;UNCONFIRMED&quot;.  What did I make wrong?<br />
 <br />
Kind Regards, <br />                            Eckard Klotz</font>

Re: [Doxygen-develop] [Doxygen-users] \li2, \li3 revisited (was: Help With Aliases Command)

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

On 21 feb 2008, at 23:45, Matthew Woehlke wrote:

> (thread: http://thread.gmane.org/gmane.text.doxygen.general/6586)
>
> Jake Colman wrote:
>> Matthew Woehlke writes:
>>> Should I try to dust off my patch for these?
>>
>> I certainly think that you should.  I just submitted a patch for ti
>> support "\default" as a new command that behaves like "\param". I  
>> hope
>> that Dimitri accepts it since I believe that a "Defaults" section  
>> would
>> be very useful.  I also think that a generic solution using "\li2[3]"
>> would be useful as well.
>
> This seems to be the patch I have lying around. Trying to reconstruct
> this from the 20k (most of that auto-generated BS, granted) of diff I
> have vs. the base 1.4.7 sources would be... interesting, so hopefully
> this works. No guesses how well it will apply against current svn,  
> though.
>
> Dmitri, can we revisit this? I'm happy to see about getting it cleaned
> up against current svn if you'd be willing to accept it.

Yes, I'm interested in a patch for this if it provides a solution to  
make
\param like commands.

Regards,
   Dimitri

[Doxygen-develop] Patch to suppress QFile warning when documenting VHDL

[Keith J O. <kjo...@Ra...>]

Greetings,
Here is a small patch against the current Doxygen SVN head to suppress 
QFile warnings when parsing VHDL files.


Index: vhdlscanner.l
===================================================================
--- vhdlscanner.l       (revision 613)
+++ vhdlscanner.l       (working copy)
@@ -1668,6 +1668,7 @@
   current=0;
 
   groupLeaveFile(yyFileName,yyLineNr);
+  inputFile.close();
 
   //mergeBrief(current_root);
   //mergeGrouping(current_root,0)



Regards,
Keith

Re: [Doxygen-develop] 1.5.5 and Fortran

[Davide C. <dc...@ar...>]

> Hi,
> 
>> I try to use doxygen 1.5.5 (svn 612 ) with my fortran project.
>> Unfortunately I get the following error
>>
>> Preprocessing C:/Users/Alin M Elena/tdtbuj/source/Constants.f90...
>> Parsing file C:/Users/Alin M Elena/tdtbuj/source/Constants.f90...
>> parse error in end
>> <scopename>********************************************************************
>> Error in file C:/Users/Alin M Elena/tdtbuj/source/Constants.f90 line: 185,
>> state: 4
> I tried SVN version several days ago and it did not work for me
> either. Unfortunately, I do not have time to look into it.
> 
> I think I'll have some time next week to fix this and look through
> some issues in bugzilla.
> 
> Oleg

Hi Oleg and the others,
	I gave a try to the new version and I also got the same error with 
fortran, after some debugging I noticed that the problem is that 
constructs like ENDIF or READ(unit,END=20) are treated like END MODULE 
or END SUBROUTINE and so on; the following changes in fortranscanner.l 
RE's work for me:

<InterfaceBody>"end"({BS_}"interface")?.*
changed to
<InterfaceBody>^{BS}"end"({BS_}"interface".*)?

<Start,ModuleBody>"end"({BS_}(module|program))?.*
changed to
<Start,ModuleBody>^{BS}"end"({BS_}(module|program).*)?{BS}$

<SubprogBody>"end"({BS_}{SUBPROG})?.*
changed to
<SubprogBody>^{BS}"end"({BS_}{SUBPROG}.*)?{BS}$

But of course I am not a lex expert, so they may not be the correct 
ones, especially I do not understand how newline are managed in 
fortranscanner, so something may be wrong in that sense.

Hope this helps, Davide

-- 
__________________________________________________________
Davide Cesari	ARPA-Servizio Idro Meteorologico      __
  tel       (39) 051/525926                            ||\
  fax       (39) 051/6497501                           |||\
  e-mail    dc...@ar...                        |||/
  www       http://www.arpa.emr.it/sim                 ---
  Address:  ARPA-SIM, Viale Silvani 6, 40122 Bologna, Italy
__________________________________________________________