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

Re: [Doxygen-develop] [PATCH] properly track static-like attribute after anonymous namespace in C++

[Anthony F. <ant...@gm...>]

Dimitri --

On Sat, Mar 9, 2013 at 3:35 AM, Anthony Foiani <ant...@gm...>wrote:

> Dimitr --


Sorry for truncating your name.  Typing too fast, and it's almost 04:00
here.  Very sorry about that.

Thanks,
Tony

Re: [Doxygen-develop] [PATCH] properly track static-like attribute after anonymous namespace in C++

[Anthony F. <ant...@gm...>]

Dimitr --

On Sat, Mar 9, 2013 at 3:28 AM, Dimitri van Heesch <do...@gm...>wrote:

> Hi Anthony,
>
> Thanks for the patch. Do you also have an example that shows the problem?
>

This is related to the test-case I sent out a few days ago, in the thread:
http://doxygen.10944.n7.nabble.com/function-not-getting-documented-tc5709.html

The sample is still there, and before/after runs with upstream and
upstream+patch seems to show that this fixes it.

(More importantly, this fix "makes sense", at a certain level.  I do not
entirely understand how doxygen is structured, but I can do input
manipulations (where I change which function is first after an anonymous
namespace -- and that changes which function fails to appear in the docs!)

I have a larger patch to leverage your existing-but-commented-out debugging
messages, in the works.  That was what let me get here even this quickly --
so thank you yet again!

Regards,
Anthony Foiani

Re: [Doxygen-develop] [PATCH] properly track static-like attribute after anonymous namespace in C++

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

Hi Anthony,

Thanks for the patch. Do you also have an example that shows the problem?

Regards,
  Dimitri

On Mar 9, 2013, at 11:13 , Anthony Foiani <ant...@gm...> wrote:

> Greetings!
> 
> I was having issues with various functions not getting documented.  After a few hours of debugging, it seems that C++ anonymous namespaces "leak" their static-like cloaking onto the first function after the close of anonymous namespace.
> 
> I'm not sure this is a 100% correct fix, but it works for my code base.
> 
> Thanks,
> Tony
> <reset-static-after-anon-ns.patch>------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
> endpoint security space. For insight on selecting the right partner to 
> tackle endpoint security challenges, access the full report. 
> http://p.sf.net/sfu/symantec-dev2dev_______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] [PATCH] Improved LaTeX output

[Markus G. <mg...@we...>]

Hi,

While trying to customize the LaTeX font settings for the user
documentation of my project, I noticed a number of issues in the
generated LaTeX output. Please find a description and a patch
against the current HEAD of svn (r841) in the bugtracker:

	https://bugzilla.gnome.org/show_bug.cgi?id=694760

I would be happy if the proposed changes would be included in
the distribution. However, I'm also open for discussion in case
you have concerns or any other feedback. Also, please let me
know if you would prefer a series of smaller patches and I'll
try to break it down into pieces.

Thanks,
Markus

Re: [Doxygen-develop] Man page generation problem with _8

[Jan R. <jan...@co...>]

Hi,

Sorry for duplicity, but I forgot that bug 650004 was filed already in 2011 [1].
Files for reproducing the issue are now attached.

Can I do anything else to help in fixing this bug?

Jan

[1] https://bugzilla.gnome.org/show_bug.cgi?id=650004


On Feb 14, 2013, at 20:10, Jan Ruzicka wrote:

> Hi
> 
> Doxygen is refusing to create man pages with dot in their name.
> 
> /** 
>    \page blah.ini blah.ini
> 
> The blah.ini consists of lore ipsum 
> 
> */
> 
> A file blah_8ini.3 is created and title is blah_8ini instead of blah.ini .
> 
> I understand that it is caused by escaping the names, but quick searching trough the code did not show where it happens.
> 
> Is there a way to allow for file names and titles to contain '.' in the name? 
> 
> Use case:
>   a description of a data file structure in a source code.
> 
>   End user should be able to do 
>           $ man -M ./man blah.ini
> 
> For example the man.config has its nice manual page.
> 
> Should I file a bug on bugzilla?
> 
> Thanks
> Jan
> 
> Jan Ruzicka
> Senior Software Engineer
> Comtech Mobile Datacom Corporation
> 20430 Century Blvd, Germantown, MD 20874
> Office: 240-686-3300
> Fax: 240-686-3301
> 
> The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.
> 
> 
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013 
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop

Jan Ruzicka
Senior Software Engineer
Comtech Mobile Datacom Corporation
20430 Century Blvd, Germantown, MD 20874
Office: 240-686-3300
Fax: 240-686-3301
 
The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

Re: [Doxygen-develop] don't put closing parenthesis on its own line

[John S. <jsc...@gm...>]

On Wed, Feb 27, 2013 at 3:57 PM, Anthony Foiani
<ant...@gm...> wrote:
> On Wed, Feb 27, 2013 at 1:22 PM, John Scipione <jsc...@gm...> wrote:
>> On Tue, Feb 26, 2013 at 2:32 AM, Anthony Foiani
>> > I don't know if it is intentional or not, but I found that the current
>> > Doxygen output for multiple (2-or-more) argument functions to be
>> > sub-optimal.
>> Hey there, perhaps in some cases the extra space is not needed, but,
>> in others it adds something.
> I guess I still find that inconsistent.  Why does a 2-arity function require
> that extra space, when a 1-arity function doesn't?
>
> Your example demonstrates the issue:
>
> status_t BArchivable::Archive ( BMessage * into,
>                                 bool       deep = true
>                               )            const [virtual]
>
> static BArchivable * BArchivable::Instantiate ( BMessage * archive )
> [static]
>
> Why does a 1-arity function get the "snug" parenthesis, while the 2-arity
> gets the extra line?  To consistently apply your look, the second one should
> look like:
>
> static BArchivable * BArchivable::Instantiate ( BMessage * archive
>                                               )            [static]
>
> Not my cup of tea at all.  :(
>
> Out of curiosity, what does the corresponding original source code look
> like?  I can't recall having ever seen any C++ or Java that looked anything
> like that, and I suspect that I am trying to get my docs to look more like
> my code in this regard.  I've seen all these styles, and used most of them
> at one time or another:

The line from the header file looks like this:

virtual status_t Archive(BMessage* into, bool deep = true) const;

all in one line. In Doxygen this gets translated into multiple lines
for style reasons.

> retType function( argType arg, argType arg ) modifier;
>
> retType function( argType arg,
>                   argType arg ) modifier;
>
> retType
> function( argType arg, argType arg ) modifier;
>
> retType
> function( argType arg,
>           argType arg ) modifier;
>
> retType
> function(
>     argType arg,
>     argType arg
> ) modifier;
>
> I don't think I've never seen anything like the "align modifiers with arg
> names".
>
> (Then again, I know lots of people who are in love with the "comma at the
> beginning of the line" style for arguments, and that drives me completely up
> the wall.  Tastes vary.  :)
>
>>
>> If you really want this to work though you'd need to add a colspan="2"
>> to that ending <td> for only the last parameter. It would look like
>> this:
>>
>> +    t << "          <td colspan=\"2\">";
>>
>> So that the const, virtual, etc. specifiers would span both the param
>> type and param name columns. Make that change and I could get behind
>> this patch.
>
> Except I *don't* want them lined up with the arg list, because they're not
> arguments: they're something else.
>
> If you feel they *should* be aligned with the arg list, then I would expect
> you'd request the same alignment for 1-arity functions as well.
>
> I think that I'll either respin the patch to make this a config option, or
> just use my patched build.  I don't see any reason at all for the
> inconsistency...

My suggestion to use colspan="2" was so that if you had a bunch of
specifiers const, virtual, static, etc. they wouldn't wrap at the end
of the column name. My suggestion would basically make it look like
your last example, sorta like this

retType function( argumentType argName1,
                          argumentType argName2 = NULL
                        ) specifier1 [specifier2] [specifier3]

If you don't have the colspan="2" you'll get this instead:

retType function( argumentType argName1,
                          argumentType argName2 = NULL
                        ) specifier1
                          [specifier2]
                          [specifier3]

because the specifiers will wrap with argumentType.

I guess if it's not your cup of tea there's not a lot that I can do
about it. Doxygen is just not designed to fit everyones particular
personal style. If it had a template system to customize the output...
one can dream.

John Scipione
PS: I'm not a doxygen developer, just a user, so, take what I say with
a grain of salt.

Re: [Doxygen-develop] don't put closing parenthesis on its own line

[Anthony F. <ant...@gm...>]

John --

Thanks for the feedback.  I think I have to respectively disagree, but it's
interesting to hear other points of view.  More detailed reply inline.

On Wed, Feb 27, 2013 at 1:22 PM, John Scipione <jsc...@gm...> wrote:

> On Tue, Feb 26, 2013 at 2:32 AM, Anthony Foiani
> <ant...@gm...> wrote:
> > Greetings.
> >
> > I don't know if it is intentional or not, but I found that the current
> > Doxygen output for multiple (2-or-more) argument functions to be
> > sub-optimal.  It wants to render it like so:
> >
> > retType
> > myFunction( Type1 arg1,
> >           Type2 arg2
> >           )
> >
> > In case that formatting gets mangled, you can see the difference in
> > this sample page, pointed out by PovAddict:
> >
> >
> http://www.stack.nl/~dimitri/doxygen/manual/examples/overload/html/class_test.html
> >    or: http://preview.tinyurl.com/avovthd
> >
> > I don't see any reason for this extra space, not even "const" or
> > similar.  After all, 0- and 1-arity functions don't get the extra
> > space.
>
> Hey there, perhaps in some cases the extra space is not needed, but,
> in others it adds something. Here is an example from the heavily
> customized but Doxygen-generated docs of my project (Haiku):
>
>
> http://api.haiku-os.org/classBArchivable.html#a256d5d912ec4e9a44be9054ee4d925f0
>
> It looks fine in this case to have the extra space and lines up the
> const with the parameter name instead of the parameter type.
>

I guess I still find that inconsistent.  Why does a 2-arity function
require that extra space, when a 1-arity function doesn't?

Your example demonstrates the issue:

status_t BArchivable::Archive ( BMessage * into,
                                bool       deep = true
                              )            const [virtual]

static BArchivable * BArchivable::Instantiate ( BMessage * archive )
[static]

Why does a 1-arity function get the "snug" parenthesis, while the 2-arity
gets the extra line?  To consistently apply your look, the second one
should look like:

static BArchivable * BArchivable::Instantiate ( BMessage * archive
                                              )            [static]

Not my cup of tea at all.  :(

Out of curiosity, what does the corresponding original source code look
like?  I can't recall having ever seen any C++ or Java that looked anything
like that, and I suspect that I am trying to get my docs to look more like
my code in this regard.  I've seen all these styles, and used most of them
at one time or another:

retType function( argType arg, argType arg ) modifier;

retType function( argType arg,
                  argType arg ) modifier;

retType
function( argType arg, argType arg ) modifier;

retType
function( argType arg,
          argType arg ) modifier;

retType
function(
    argType arg,
    argType arg
) modifier;

I don't think I've never seen anything like the "align modifiers with arg
names".

(Then again, I know lots of people who are in love with the "comma at the
beginning of the line" style for arguments, and that drives me completely
up the wall.  Tastes vary.  :)


> If you really want this to work though you'd need to add a colspan="2"
> to that ending <td> for only the last parameter. It would look like
> this:
>
> +    t << "          <td colspan=\"2\">";
>
> So that the const, virtual, etc. specifiers would span both the param
> type and param name columns. Make that change and I could get behind
> this patch.
>

Except I *don't* want them lined up with the arg list, because they're not
arguments: they're something else.

If you feel they *should* be aligned with the arg list, then I would expect
you'd request the same alignment for 1-arity functions as well.

I think that I'll either respin the patch to make this a config option, or
just use my patched build.  I don't see any reason at all for the
inconsistency...

Either way, thanks for the reply.

Best regards,
Anthony Foiani

Re: [Doxygen-develop] don't put closing parenthesis on its own line

[John S. <jsc...@gm...>]

On Tue, Feb 26, 2013 at 2:32 AM, Anthony Foiani
<ant...@gm...> wrote:
> Greetings.
>
> I don't know if it is intentional or not, but I found that the current
> Doxygen output for multiple (2-or-more) argument functions to be
> sub-optimal.  It wants to render it like so:
>
> retType
> myFunction( Type1 arg1,
>           Type2 arg2
>           )
>
> In case that formatting gets mangled, you can see the difference in
> this sample page, pointed out by PovAddict:
>
>    http://www.stack.nl/~dimitri/doxygen/manual/examples/overload/html/class_test.html
>    or: http://preview.tinyurl.com/avovthd
>
> I don't see any reason for this extra space, not even "const" or
> similar.  After all, 0- and 1-arity functions don't get the extra
> space.

Hey there, perhaps in some cases the extra space is not needed, but,
in others it adds something. Here is an example from the heavily
customized but Doxygen-generated docs of my project (Haiku):

http://api.haiku-os.org/classBArchivable.html#a256d5d912ec4e9a44be9054ee4d925f0

It looks fine in this case to have the extra space and lines up the
const with the parameter name instead of the parameter type.

If you really want this to work though you'd need to add a colspan="2"
to that ending <td> for only the last parameter. It would look like
this:

+    t << "          <td colspan=\"2\">";

So that the const, virtual, etc. specifiers would span both the param
type and param name columns. Make that change and I could get behind
this patch.

Thanks,
John Scipione

Re: [Doxygen-develop] [PATCH] warn about maintaining line numbers with INPUT_FILTER

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

Hi Anthony,

On Feb 26, 2013, at 8:38 , Anthony Foiani <ant...@gm...> wrote:

> Greetings.
> 
> I recently spent far longer than I should have, trying to track down
> why my code anchors were offset.
> 
> It turns out that I had been using:
> 
>   INPUT_FILTER = "grep -v 'something to ignore'"
> 
> But this removed the lines entirely; that meant that the code scanner
> "saw" different line numbers than the cpp-to-html generator.  Once I
> realized what was happening, I got the same result by using:
> 
>   INPUT_FILTER = "sed -e 's/.*something to ignore.*//'"
> 
> But I might have saved myself a few hours if I had seen a warning about it.  :)
> 
> Since I was already doing the other patch, here's one to add a bit of
> warning text about this possibility.

Thanks, I'll include it.

Regards,
  Dimitri

[Doxygen-develop] [PATCH] warn about maintaining line numbers with INPUT_FILTER

[Anthony F. <ant...@gm...>]

Greetings.

I recently spent far longer than I should have, trying to track down
why my code anchors were offset.

It turns out that I had been using:

   INPUT_FILTER = "grep -v 'something to ignore'"

But this removed the lines entirely; that meant that the code scanner
"saw" different line numbers than the cpp-to-html generator.  Once I
realized what was happening, I got the same result by using:

   INPUT_FILTER = "sed -e 's/.*something to ignore.*//'"

But I might have saved myself a few hours if I had seen a warning about it.  :)

Since I was already doing the other patch, here's one to add a bit of
warning text about this possibility.

Thanks once again for the excellent tool!

Best regards,
Anthony Foiani

[Doxygen-develop] don't put closing parenthesis on its own line

[Anthony F. <ant...@gm...>]

Greetings.

I don't know if it is intentional or not, but I found that the current
Doxygen output for multiple (2-or-more) argument functions to be
sub-optimal.  It wants to render it like so:

retType
myFunction( Type1 arg1,
          Type2 arg2
          )

In case that formatting gets mangled, you can see the difference in
this sample page, pointed out by PovAddict:

   http://www.stack.nl/~dimitri/doxygen/manual/examples/overload/html/class_test.html
   or: http://preview.tinyurl.com/avovthd

I don't see any reason for this extra space, not even "const" or
similar.  After all, 0- and 1-arity functions don't get the extra
space.

And I personally dislike the aesthetic, although I can appreciate that
this is less clear-cut, and that others might have other opinions.
(As PovAddict said on IRC: "for something like this, you'll get
bikeshedding no matter where you post it"...)

Anyway, I cooked up a small patch to get rid of the extra space.  As a
bonus, it is a net removal of lines of code.  Please feel free to
incorporate or discard.

Thanks, either way, for a fantastic tool.

Best regards,
Anthony Foiani

[Doxygen-develop] Bug 641851

[Kevin M. <dol...@ai...>]

Dimitri,

On the bug below, Phillip is asking if he should open a new bug.  I 
think it is best to keep .cpp and .md bugs separated in situations 
involving incorrect line numbers in warnings, but I will let you decide 
how you want to handle the situation.  I did triage the original 
problem in the bug, but I am not familiar with .md files, which is 
another reason why I am letting you decide on this issue.

https://bugzilla.gnome.org/show_bug.cgi?id=641851

Kevin McBride
dol...@ai...

Re: [Doxygen-develop] Comment beginning with "// Author" suppresses doc generation

[dougkramer <dou...@gm...>]

I confirmed this issue occurs with doxygen 1.8.3.1, so submitted it as a bug:
https://bugzilla.gnome.org/show_bug.cgi?id=694218




--
View this message in context: http://doxygen.10944.n7.nabble.com/Comment-beginning-with-Author-suppresses-doc-generation-tp5669p5671.html
Sent from the Doxygen - Development mailing list archive at Nabble.com.

Re: [Doxygen-develop] Comment beginning with "// Author" suppresses doc generation

[Erik Z. <ze...@ma...>]

On Sat, Feb 16, 2013 at 9:00 AM, dougkramer <dou...@gm...> wrote:
> [cross-posted to doxygen-users]
>
> Has anyone else seen this?  Should I submit a bug?

Try the latest version first.  The current version is 1.8.3.1.

Erik

> PROBLEM:
> When I run doxygen on Objective-C source code with the following code block,
> no documentation is generated for that method -- no signature, parameters or
> doc comment.
>
> CAUSE:
> I tracked the problem down to this:
> A comment line that starts with the string "// Author" prevents entire
> documentation for that method from being generated
>
> SOLUTION:
> Add a word before "Author", such as "// The authorization has finished"
>
> -------------------------------------------------------------
> // A protocol implemented by the client.
> @protocol MyClassDelegate
>
> // Authorization is finished
> - (void)finishedWithAuth:(OAuth2Authentication *)auth;
>
> @end
> --------------------------------------------------------------
>
> $ doxygen --version
> 1.7.6.1
>
>
>
> --
> View this message in context: http://doxygen.10944.n7.nabble.com/Comment-beginning-with-Author-suppresses-doc-generation-tp5669.html
> Sent from the Doxygen - Development mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop



-- 
*************************************************
Erik Zeek
ze...@ma...
*************************************************
Against stupidity the very gods
Themselves contend in vain.
  - Johann Christoph Friedrich von Schiller (1801)
*************************************************

[Doxygen-develop] Comment beginning with "// Author" suppresses doc generation

[dougkramer <dou...@gm...>]

[cross-posted to doxygen-users]

Has anyone else seen this?  Should I submit a bug? 

PROBLEM: 
When I run doxygen on Objective-C source code with the following code block,
no documentation is generated for that method -- no signature, parameters or
doc comment. 

CAUSE: 
I tracked the problem down to this: 
A comment line that starts with the string "// Author" prevents entire
documentation for that method from being generated 

SOLUTION: 
Add a word before "Author", such as "// The authorization has finished" 

------------------------------------------------------------- 
// A protocol implemented by the client. 
@protocol MyClassDelegate 

// Authorization is finished 
- (void)finishedWithAuth:(OAuth2Authentication *)auth; 

@end 
-------------------------------------------------------------- 

$ doxygen --version 
1.7.6.1 



--
View this message in context: http://doxygen.10944.n7.nabble.com/Comment-beginning-with-Author-suppresses-doc-generation-tp5669.html
Sent from the Doxygen - Development mailing list archive at Nabble.com.

[Doxygen-develop] Man page generation problem with _8

[Jan R. <jan...@co...>]

Hi

Doxygen is refusing to create man pages with dot in their name.

/** 
    \page blah.ini blah.ini

The blah.ini consists of lore ipsum 

*/

A file blah_8ini.3 is created and title is blah_8ini instead of blah.ini .

I understand that it is caused by escaping the names, but quick searching trough the code did not show where it happens.

Is there a way to allow for file names and titles to contain '.' in the name? 

Use case:
   a description of a data file structure in a source code.

   End user should be able to do 
           $ man -M ./man blah.ini
   
For example the man.config has its nice manual page.

Should I file a bug on bugzilla?

Thanks
Jan

Jan Ruzicka
Senior Software Engineer
Comtech Mobile Datacom Corporation
20430 Century Blvd, Germantown, MD 20874
Office: 240-686-3300
Fax: 240-686-3301
 
The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

Re: [Doxygen-develop] Doxygen website works now (was: does not load in firefox 18.0.2)

[Jan R. <jan...@co...>]

Hi Dimitri,

It is working for me now too.
It may have been something with our internal proxy.
Thanks and sorry to bother.

Jan
On Feb 7, 2013, at 15:19, Dimitri van Heesch wrote:

> Hi Jan,
> 
> On Feb 6, 2013, at 23:48 , Jan Ruzicka <jan...@co...> wrote:
> 
>> Hi
>> 
>> I'm trying to see the main page for Doxygen[1] and it is not loading under Firefox 18.0.2 on OSX.
>> It seems to just hang there, but it loads the manual pages[2].
>> 
>> Safari shows main pages okay.
>> Somehow Firefox seems to have problems with jquery.js for main page[3].
>> 
>> Is it something with the site/re-genearted pages  or with Firefox?
>> Does the jquery.js for main page[3] exist?
> 
> All 3 links work fine for me with the same browser version and OS!
> Maybe a firefox plugin that causes this for you, or a caching issue?
> 
> Regards,
>  Dimitri
> 
>> 
>> Jan
>> 
>> [1] http://www.stack.nl/~dimitri/doxygen/index.html
>> [2] http://www.stack.nl/~dimitri/doxygen/manual/index.html
>> [3] http://www.stack.nl/~dimitri/doxygen/jquery.js
> 

Jan Ruzicka
Senior Software Engineer
Comtech Mobile Datacom Corporation
20430 Century Blvd, Germantown, MD 20874
Office: 240-686-3300
Fax: 240-686-3301
 
The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

Re: [Doxygen-develop] Doxygen website does not load in firefox 18.0.2

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

Hi Jan,

On Feb 6, 2013, at 23:48 , Jan Ruzicka <jan...@co...> wrote:

> Hi
> 
> I'm trying to see the main page for Doxygen[1] and it is not loading under Firefox 18.0.2 on OSX.
> It seems to just hang there, but it loads the manual pages[2].
> 
> Safari shows main pages okay.
> Somehow Firefox seems to have problems with jquery.js for main page[3].
> 
> Is it something with the site/re-genearted pages  or with Firefox?
> Does the jquery.js for main page[3] exist?

All 3 links work fine for me with the same browser version and OS!
Maybe a firefox plugin that causes this for you, or a caching issue?

Regards,
  Dimitri

> 
> Jan
> 
> [1] http://www.stack.nl/~dimitri/doxygen/index.html
> [2] http://www.stack.nl/~dimitri/doxygen/manual/index.html
> [3] http://www.stack.nl/~dimitri/doxygen/jquery.js

[Doxygen-develop] Doxygen website does not load in firefox 18.0.2

[Jan R. <jan...@co...>]

Hi

I'm trying to see the main page for Doxygen[1] and it is not loading under Firefox 18.0.2 on OSX.
It seems to just hang there, but it loads the manual pages[2].

Safari shows main pages okay.
Somehow Firefox seems to have problems with jquery.js for main page[3].

Is it something with the site/re-genearted pages  or with Firefox?
Does the jquery.js for main page[3] exist?

Jan

[1] http://www.stack.nl/~dimitri/doxygen/index.html
[2] http://www.stack.nl/~dimitri/doxygen/manual/index.html
[3] http://www.stack.nl/~dimitri/doxygen/jquery.js

Jan Ruzicka
Senior Software Engineer
Comtech Mobile Datacom Corporation
20430 Century Blvd, Germantown, MD 20874
Office: 240-686-3300
Fax: 240-686-3301
 
The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

Re: [Doxygen-develop] [PATCH] Add configuration option LATEX_EXTRA_FILES

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

Hi Markus,

On Jan 28, 2013, at 18:32 , Markus Geimer <mg...@we...> wrote:

> Hi,
> 
> In the context of my current project it would be very convenient to let
> doxygen copy a bunch of additional files to the LaTeX output directory,
> similar to what the HTML_EXTRA_FILES configuration variable provides for
> HTML.
> 
> Please find a patch against the current HEAD of svn (r840) attached. It
> would be cool if it could find its way into the next release.

Thanks, I'll include it.

Regards,
  Dimitri

[Doxygen-develop] Patch for PROJECT_LOGO Option

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

Dimitri,

I am considering modifying the PROJECT_LOGO option to accept an optional
URL.  It would appear as follows:

PROJECT_LOGO = mylogo.gif : http://www.mysite.com

The HTML code would generate an anchor tag so that clicking on the image
would activate the URL.

Would you accept a patch that implements that functionality?  If not, I
will not bother doing it.

Thanks.

...Jake


-- 
Jake Colman | Director, Software Development
PRINCIPIA | 101 West Elm Street | Suite 620 | Conshohocken | PA 19428
t: +1 (610) 755 9786 | f: +1 (201) 221 8929
e: co...@pp... | w: www.principiaSFP.com
Know your investments

[Doxygen-develop] [PATCH] Add configuration option LATEX_EXTRA_FILES

[Markus G. <mg...@we...>]

Hi,

In the context of my current project it would be very convenient to let
doxygen copy a bunch of additional files to the LaTeX output directory,
similar to what the HTML_EXTRA_FILES configuration variable provides for
HTML.

Please find a patch against the current HEAD of svn (r840) attached. It
would be cool if it could find its way into the next release.

Thanks,
Markus

Re: [Doxygen-develop] [PATCH] add column info and a sqlite3 generator

[Adrian M N. <gr...@gm...>]

On Jan 25, 2013 10:56 PM, "Dimitri van Heesch" <di...@st...> wrote:

> Hi Adrian,
>
> Thanks for the patches. I'll look at them in more detail.
>
> Do you also have something that uses the sqlite database
> to produce DXR like output that you can share?
> Otherwise everyone would have to write something like that themselves.

I have a python script to query the database. I'm currently using it from
cli,to test sqlitegen, but after it stabilizes, I'll modify htmlgen to add
dxr-like functionality, like symbol details and search.

> On Jan 25, 2013, at 10:00 , Adrian M Negreanu <gr...@gm...> wrote:
>
> > minor changes to 0007-sqlite3gen-generate-sqlite3.patch
> > (reattached )
> >
> > On Thu, Jan 24, 2013 at 2:14 PM, Adrian M Negreanu <gr...@gm...>
wrote:
> >> Hi Dimitry,
> >>
> >> I have been working on adding support for sqlite3 generator
> >> and along doing so, I needed to enable the fprintf's in the *.l files.
> >>
> >> At first I used DXR[1] as a consumer for the xml generated by doxygen,
> >> and for this I needed to export the Definition column.
> >>
> >> After seeing a lot of redundancy in DXR (such as its limited syntax
> >> highlighter),
> >> I though of adding sqlite3 support to doxygen, such that the HTML pages
> >> can query the sqlite3 directly to be quite similar to DXR.
> >>
> >> A change note-worthy is that the reference dicts are now keyed by
> >> the file location (file:line:column); they used to be keyed by the
> >> source-reference name.
> >>
> >> On the sqlite3 side, the tables are not normalized, but I think it's
ok for now.
> >>
> >> Please let me know your thoughts on this patch set.
> >>
> >>
> >> [1] : http://dxr.mozilla.org/
> >>
> >> --
> >> Regards!
> >> http://groleo.wordpress.com
> >
> >
> >
> > --
> > Regards!
> > http://groleo.wordpress.com
> > <0007-sqlite3gen-generate-sqlite3.patch>
>

Re: [Doxygen-develop] [PATCH] add column info and a sqlite3 generator

[Dimitri v. H. <di...@st...>]

Hi Adrian,

Thanks for the patches. I'll look at them in more detail.

Do you also have something that uses the sqlite database
to produce DXR like output that you can share? 
Otherwise everyone would have to write something like that themselves.

Regards,
  Dimitri

On Jan 25, 2013, at 10:00 , Adrian M Negreanu <gr...@gm...> wrote:

> minor changes to 0007-sqlite3gen-generate-sqlite3.patch
> (reattached )
> 
> On Thu, Jan 24, 2013 at 2:14 PM, Adrian M Negreanu <gr...@gm...> wrote:
>> Hi Dimitry,
>> 
>> I have been working on adding support for sqlite3 generator
>> and along doing so, I needed to enable the fprintf's in the *.l files.
>> 
>> At first I used DXR[1] as a consumer for the xml generated by doxygen,
>> and for this I needed to export the Definition column.
>> 
>> After seeing a lot of redundancy in DXR (such as its limited syntax
>> highlighter),
>> I though of adding sqlite3 support to doxygen, such that the HTML pages
>> can query the sqlite3 directly to be quite similar to DXR.
>> 
>> A change note-worthy is that the reference dicts are now keyed by
>> the file location (file:line:column); they used to be keyed by the
>> source-reference name.
>> 
>> On the sqlite3 side, the tables are not normalized, but I think it's ok for now.
>> 
>> Please let me know your thoughts on this patch set.
>> 
>> 
>> [1] : http://dxr.mozilla.org/
>> 
>> --
>> Regards!
>> http://groleo.wordpress.com
> 
> 
> 
> -- 
> Regards!
> http://groleo.wordpress.com
> <0007-sqlite3gen-generate-sqlite3.patch>

[Doxygen-develop] thoughts on replacing qtools with stl ?

[Adrian M N. <gr...@gm...>]

Hi,

I discovered QList to be pretty slow compared to std::list.
I did the test in a rough way by just iterating g_inputFiles in
doxygen.cpp:parseFiles().
Ofc, after the call site of parseFiles() I exited doxygen thus no
documentation was generated.

The times obtained were 29seconds using StringList vs. 2seconds using
std::list<QCString>.
The sources on which I ran doxygen consisted of
libva/libdrm/mesa-library which amounts to
a few thousands of files.

Now, considering that QList is used in other places, is it sane to
also use std::list instead of QList ?

thanks