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

Re: [Doxygen-develop] GIT

[Peter M. <ped...@gm...>]

Am looking more into this, but again dont want to waste time..

But.. if the move to github.. (or any git hosting).. in gitlab...
then
we need to migrate..
I can help with that as done this before.. once on a project with 5 devs..
ie svn to git migration..

http://git-scm.com/book/en/Git-and-Other-Systems-Migrating-to-Git

###########
Problems
##########'#
Authors who have identities..
but there are ways around this.. but its complex.. and easier with new
identities and matching later..

Maintaining backward svn and sf.net
We can push that another way, by making every commit to master,
thereby "commit" to trunk as sf.net if needed...
I am still an advocate for svn as its don't download the "whole history,
instead just changes" and this is good downstream..
So we can make it mix both ways..later...

Do make it automated.. though..

We need to use a build farm.. eg Jenkins

RedHat are still testing their openshift platform
and got a version running here
https://doxygen-pedromorgan.rhcloud.com
login=doxygen
pass=h2o

and thats a couple of job that poll the repos,
pull source
check for changes
and recompile the source on a remote machine.. which is mine atmo
but any app can be one..

We also build rpm,s etc same way
and update website..

So that is the way to go imho, and the way a few other projects go..

Also..for dimirti..
with github.com..
u can trun doxygen from an user into an "organisation". .which is a good
idea...
This means u can then add admins etc and allow others to manage parts etc..

anyway..
Will start a svn to git migration id u give the "nod" to go ahead..
as I got the stuff on machine and been there done that so it should be ok..

Pete


On 26 April 2013 23:58, Peter Morgan <ped...@gm...> wrote:

> Hi all,
>
> This is following on from a  previous  discussion about git...
>
> I see that
> https://github.com/doxygen
> is there and its dimitri etc..
>
> But also a search for doxygen shows so many mirrors.. etc etc all outta
> date..
>
> So is there a possibility to at least create the github.com version as
> official..
> so we can all fork..
>
> There are tools to import and if help is required then am around 2 assist
> ...
> But generally speakin i would expect a
> "master" - branch which is stable
> "next" - which is the next dev flavour (like trunk/)
>
> and all the tags etc should import with
> git svn checkout..
>
> There are so many clones though... we'd save github/aws a lot of disk
> space..... maybe
> https://github.com/search?q=doxygen&ref=cmdform
>
> regards
> Pete
>
>
>

[Doxygen-develop] GIT

[Peter M. <ped...@gm...>]

Hi all,

This is following on from a  previous  discussion about git...

I see that
https://github.com/doxygen
is there and its dimitri etc..

But also a search for doxygen shows so many mirrors.. etc etc all outta
date..

So is there a possibility to at least create the github.com version as
official..
so we can all fork..

There are tools to import and if help is required then am around 2 assist
...
But generally speakin i would expect a
"master" - branch which is stable
"next" - which is the next dev flavour (like trunk/)

and all the tags etc should import with
git svn checkout..

There are so many clones though... we'd save github/aws a lot of disk
space..... maybe
https://github.com/search?q=doxygen&ref=cmdform

regards
Pete

[Doxygen-develop] RPM packaging doxygen.spec : small fixes

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

Hi

The Mock (clean package rebuild) was showing missing dependencies on flex and bison.
They are tested for by the doxygen build configuration script.

The rpmlint was complaining about:
 - license as it doesn't mention version of GPL in a way it expects.
 - package summary ending in dot
 - a redundant Provides section with package name that is added to package automatically.

Changes are attached below.
Jan

--- doxygen.spec.old	2013-04-25 16:03:54.000000000 -0400
+++ doxygen.spec.new	2013-04-25 16:04:04.000000000 -0400
@@ -9,19 +9,19 @@
 %define suexec_caller doxygen
 %define buildroot /var/tmp/%{name}-%{version}-%{revision}root
 
-Summary: A documentation system for C/C++.
+Summary: A documentation system for C/C++
 Name: doxygen
 Version: %{version}
 Release: %{revision}
 URL: http://www.stack.nl/~dimitri/doxygen/index.html
 Vendor: Dimitri van Heesch
-License: GNU General Public License
+License: GPLv2 GNU General Public License
 Group: Development/Tools
 Source: %{name}-%{version}.src.tar.gz
 BuildRoot: %{buildroot}
 BuildRequires: libstdc++-devel >= 2.96, /usr/bin/perl, /usr/bin/latex, /usr/bin/dvips, /usr/bin/gs
+BuildRequires: flex, bison
 Requires: /sbin/chkconfig, /bin/mktemp, /bin/rm, /bin/mv, libstdc++ >= 2.96
-Provides: doxygen = %{mmn}
 
 %description
 Doxygen can generate an online class browser (in HTML) and/or a



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.

[Doxygen-develop] (no subject)

[Liam S. <ls...@gm...>]

Hi,

Pardon for the cross post from doxygen-users, but does anybody know of an
existing PPA that packages recent versions of Doxygen for older Ubuntu
releases? I'm most interested in getting 1.8.3 onto x86 and x64 machines
running precise.

Thanks for any tips.

Liam

Re: [Doxygen-develop] doxygen5

[Peter M. <ped...@gm...>]

>
> I suggest NOT to combine SVN with Git (i.e. central SVN repo and Git
> on the top).
>
> definately not, this leads to all sorts of problems, and an experive
mistake on a RL project !!
However github offers svn client.. so its git repos and svn client..
but this also can be confusing, as the merge is done "server side".. and
history etc gets all messed up

But using svn as a read only mirror, grabbing the HEAD and not the history,
then it works well.
https://github.com/blog/626-announcing-svn-support

regards
pete

Re: [Doxygen-develop] doxygen5

[Peter M. <ped...@gm...>]

> > == Git ==
> >  - can the  doxygen  start to use git as its native repos. this kinda
> works, svn is not really in anymore.. (a gf u kinda dating but
> releationship is boring.. from years ago.. before your first data with csv,
> and before that your straightforward ftp date ;-)
>
> I've been experimenting with Git a bit locally and I like it, so that
> certainly a direction to go to in the future.
> What would you chose as a hosting site? GitHub?
>

Well I use gotorious, sf, github and bitbucket ..

For Doxygen I would recommend github, mainly because you can still use SVN
and github client works sweet on Windows...
(also merges can be made on the web interface)



>
> >
> > == New HTML 5 + CSS3 Output ==
> > so instead of having all complex tags everywhere, we
> > just spool out the html in html5 style..
> >
> > Css3 is the used to format and layout the document as required..
> > Css-3 can be used to full max strength
> >
>
> I'm worried about cross-browser compatibility.
> Not everyone is using the latest greatest browser.
>

Dont panic;  there are tools out there to make it backward compatible..
eg html5reset and other boilerplate project inject js and like to solve
this issue
so I dont see this as a problem


> >
> > ==========================
> > Tempalting
> > ==========================
> > The document structure and output of html needs to move into templating
> land..
> > The resason for this is simple... Presentation is not part of a document
> structure..
> >
> > In www land, which is where documentation co exists..
> > Grentlee looks good and means we can use jinga templates.
> > ie share the same stuff with a possible online inteface and rendering..
>
> I've been thinking about this as well (and the layout file is a first step
> into this
> direction). Doxygen does have many output formats, making this less
> trivial.
> Probably the best solution is to start with a new backend (or use the XML
> output as input).
>
> >
> > But this leads to the issue that grantlee uses script taags.. and QScript
>
> and that doxygen doesn't use any recent version of Qt (only the wizard
> does).
>
well looking at htmlgen.cpp, it should be pretty straightforward to drop in
qtScript
and created a "nested dictionary" for the templating.
This would mean removing almost all html from htmgen.cpp and moving it to a
template

regards
pete

Re: [Doxygen-develop] doxygen5

[Petr P. <Pr...@sk...>]

> > == Git ==
> >  - can the  doxygen  start to use git as its native repos. this kinda
> > works, svn is not really in anymore...
> 
> I've been experimenting with Git a bit locally and I like it, so that
> certainly a direction to go to in the future.
> What would you chose as a hosting site? GitHub?

My +1 for Git. I have been using CVS earlier, planning to switch to SVN.
Git seemed a bit odd at first to me; however, it was only because 
I was not used to.

I tried GitHub and it is just fine for cooperation. One can keep
the read-only copy of everything, the other can fork (i.e. clone), do 
specific updates, and ask for merging (pull request). It seems to work
fine even when more people work independently (I mean GitHub, not only 
Git -- which is such automatically :).

I suggest NOT to combine SVN with Git (i.e. central SVN repo and Git
on the top).

Regards,
   Petr

Re: [Doxygen-develop] doxygen5

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

Hi Pete,

You have lot of good ideas, so let me give you my thoughts...

On Apr 22, 2013, at 14:20 , Peter Morgan <ped...@gm...> wrote:

> Hi all,
> 
> I'm using doxygen a lot atmo. infact I been around the houses with documentation systems..
> from smart-docbook, thry to latest and worst sphinx..
> and still doxygen comes out on top..
> 
> I'm using it on these foss projects
> http://fgms.freeflightsim.org - a website and dev docs created with doxygen
> http://docs.freeflightsim.org - a spool out and interlinkof 5 projects..
> and
> http://ags-toolkit.daffodil.uk.com/ = my latest curious
> 
> Now as my background is both in web php python, js code and desktop c++ code
> 
> I think what I want to do is modify doxygen a little to make it more webiffied..
> and more automated.. even hosted..
> 
> so my needs and thoughts and questions are.. after looking at arouce are...
> 
> == Git ==
>  - can the  doxygen  start to use git as its native repos. this kinda works, svn is not really in anymore.. (a gf u kinda dating but releationship is boring.. from years ago.. before your first data with csv, and before that your straightforward ftp date ;-)

I've been experimenting with Git a bit locally and I like it, so that certainly a direction to go to in the future.
What would you chose as a hosting site? GitHub?

> 
> == Test Docs ==
> Can we create a test_docs/ directory to use as input for the stuff
> he idea here is to create a sample dorectory with the most complex styff we can make
> eg
> a main page
> a few pages of stuff
> a cladd with multiple inherit
> a spare.md file
> intermixed with namespaves in py, js, c++ et all thrown in 
> The output from this would be the test case kinda

Yes, makes sense. I've once posted this http://permalink.gmane.org/gmane.text.doxygen.devel/1127
Maybe a good starting point.

> 
> == New HTML 5 + CSS3 Output ==
> so instead of having all complex tags everywhere, we
> just spool out the html in html5 style..
> 
> This means the
> <header></header>
> <nav></nav>
> <content>
> <article></article>
> <aside></aside>
> </content>
> <nav></nav>
> <footer></footer>
> 
> And that is therefore a straightforward html5 document..
> 
> Css3 is the used to format and layout the document as required..
> Css-3 can be used to full max strength
> 

I'm worried about cross-browser compatibility. 
Not everyone is using the latest greatest browser.

> One important note here is that we want certain parts to be custom..
> eg
> The project logo could also be and url, or one aqquired wget
> The style sheet need to work as a standalone page also.. eg outside of doxy
> 
> Create a proper namespace..
> This means that one can easily customize..
> 
> I think the initial goal would be to create the test_docs and then use that output against the system sheet..
> 
> -- And Issue here is that the struct is too complex..
> -- we need to make the \ref and \page foo and "links" and \section match exactyle to a class
> eg
> \page foo My Foo PAge
> \section section_foo My Foo Section
> \subsubsection section_bar My Foo Section
> 
> style = body .page .section p {}
> style = body .page .subsubsection {}
> 
> So the selectors and structure need to ru in cocert with jquery..

Some more logical structure would be nice indeed. 
The current style had organically grown, not really designed ;-)

> 
> == Namespace ==
> We need to definately get away from classes such as "contents" etc
> This works in doxygen, but not in an mixed enviroment..
> to we need to adopt the doxygen namspace, particular in css
> eg a html with <html> style="/doxy.css">
> eg
> .doxygen p{
>   /* safe */
> }
> 
> This means that the "doxygen style sheet" can be added..
> 
> This will sork across a lot of boundaries

I never designed for mixed environments, but you are right.

> 
> ===================
> Auto Build Farm
> ===================
> We need a good autobuild part..
> This is possible with jenkins and alike..
> What we really want is the website and whole "system" etc atuo updated
> as each one of us touches the files.. 
> This is simple with jenkins, and hosting one is easy with Openshift

So far patch integration and release testing is done by me, so I haven't had a need
for continuous integration facilities. If anyone can temper with the code, this
would be needed indeed.

> 
> ==========================
> Tempalting
> ==========================
> The document structure and output of html needs to move into templating land..
> The resason for this is simple... Presentation is not part of a document structure..
> 
> In www land, which is where documentation co exists..
> Grentlee looks good and means we can use jinga templates.
> ie share the same stuff with a possible online inteface and rendering..

I've been thinking about this as well (and the layout file is a first step into this
direction). Doxygen does have many output formats, making this less trivial.
Probably the best solution is to start with a new backend (or use the XML output as input).

> 
> But this leads to the issue that grantlee uses script taags.. and QScript

and that doxygen doesn't use any recent version of Qt (only the wizard does).

> 
> Anyway..
> Those are my thoughts.. amd hacking away..
> I want the ags-toolkit to work with odxygen and my other simple page..
> But to do that, I am beter of wasting my time fixing doxygen ;-)

Agreed ;-)

Regards,
 Dimitri

P.S. Seems like your spelling checker can't keep up with your typing speed ;-)

[Doxygen-develop] doxygen5

[Peter M. <ped...@gm...>]

Hi all,

I'm using doxygen a lot atmo. infact I been around the houses with
documentation systems..
from smart-docbook, thry to latest and worst sphinx..
and still doxygen comes out on top..

I'm using it on these foss projects
http://fgms.freeflightsim.org - a website and dev docs created with doxygen
http://docs.freeflightsim.org - a spool out and interlinkof 5 projects..
and
http://ags-toolkit.daffodil.uk.com/ = my latest curious

Now as my background is both in web php python, js code and desktop c++ code

I think what I want to do is modify doxygen a little to make it more
webiffied..
and more automated.. even hosted..

so my needs and thoughts and questions are.. after looking at arouce are...

== Git ==
 - can the  doxygen  start to use git as its native repos. this kinda
works, svn is not really in anymore.. (a gf u kinda dating but
releationship is boring.. from years ago.. before your first data with csv,
and before that your straightforward ftp date ;-)

== Test Docs ==
Can we create a test_docs/ directory to use as input for the stuff
he idea here is to create a sample dorectory with the most complex styff we
can make
eg
a main page
a few pages of stuff
a cladd with multiple inherit
a spare.md file
intermixed with namespaves in py, js, c++ et all thrown in
The output from this would be the test case kinda

== New HTML 5 + CSS3 Output ==
so instead of having all complex tags everywhere, we
just spool out the html in html5 style..

This means the
<header></header>
<nav></nav>
<content>
<article></article>
<aside></aside>
</content>
<nav></nav>
<footer></footer>

And that is therefore a straightforward html5 document..

Css3 is the used to format and layout the document as required..
Css-3 can be used to full max strength

One important note here is that we want certain parts to be custom..
eg
The project logo could also be and url, or one aqquired wget
The style sheet need to work as a standalone page also.. eg outside of doxy

Create a proper namespace..
This means that one can easily customize..

I think the initial goal would be to create the test_docs and then use that
output against the system sheet..

-- And Issue here is that the struct is too complex..
-- we need to make the \ref and \page foo and "links" and \section match
exactyle to a class
eg
\page foo My Foo PAge
\section section_foo My Foo Section
\subsubsection section_bar My Foo Section

style = body .page .section p {}
style = body .page .subsubsection {}

So the selectors and structure need to ru in cocert with jquery..

== Namespace ==
We need to definately get away from classes such as "contents" etc
This works in doxygen, but not in an mixed enviroment..
to we need to adopt the doxygen namspace, particular in css
eg a html with <html> style="/doxy.css">
eg
.doxygen p{
  /* safe */
}

This means that the "doxygen style sheet" can be added..

This will sork across a lot of boundaries

===================
Auto Build Farm
===================
We need a good autobuild part..
This is possible with jenkins and alike..
What we really want is the website and whole "system" etc atuo updated
as each one of us touches the files..
This is simple with jenkins, and hosting one is easy with Openshift

==========================
Tempalting
==========================
The document structure and output of html needs to move into templating
land..
The resason for this is simple... Presentation is not part of a document
structure..

In www land, which is where documentation co exists..
Grentlee looks good and means we can use jinga templates.
ie share the same stuff with a possible online inteface and rendering..

But this leads to the issue that grantlee uses script taags.. and QScript

Anyway..
Those are my thoughts.. amd hacking away..
I want the ags-toolkit to work with odxygen and my other simple page..
But to do that, I am beter of wasting my time fixing doxygen ;-)

Pete

Re: [Doxygen-develop] Too small line height in CSS for headings

[Vaclav P. <wen...@gm...>]

On 1 April 2013 15:38, Dimitri van Heesch <do...@gm...> wrote:
>
> On Mar 21, 2013, at 16:53 , Vaclav Petras <wen...@gm...> wrote:
>
>> Hi,
>>
>> h1 and other h elements have to small line-height. When the heading is
>> long and the page is not wide enough, the heading is split into two
>> lines, then you can see that heading lines overlaps.
>>
>> The line-height reported by Firefox and Chromium is 19px which is at
>> the beginning of of doxygen.css:
>>
>> body, table, div, p, dl {
>>       font: 400 14px/19px Roboto,sans-serif;
>> }
>>
>> Sorry for not proving a patch but my CSS knowledge is very limited.
>
> Can you test how far you have to increase the 19px in order to make the
> overlapping disappear? I've now set it to 22px.

I've finally tested it and the result is 28px.

font: 400 14px/28px Roboto,sans-serif

22px works in most cases but does not work for headings where letters
like 'pqy' at upper line meets with letters like 'tlbd' at lower line.

I'm not sure where for which elements did you changed the size.
However, I was able to change it only for all text now and it is of
course not suitable for all text, it is nice only for headings.

By the way, two-line headings happens much often if \tableofcontents
is used (it did not happened formally, where there was no
\tableofcontents, even with the new CSS).

Vaclav

>
> Regards,
>   Dimitri
>

Re: [Doxygen-develop] release tarballs

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

Hi Helmut,

On Apr 6, 2013, at 12:45 , Helmut Grohne <he...@su...> wrote:

> Dear Doxygen developers,
> 
> I am writing to you on behalf of the Debian project. There are a few
> issues with the doxygen package as shipped by Debian that are imho best
> addressed upstream. Please have a look at whether this is reasonable.
> 
> In http://bugs.debian.org/569504 Jonathan Nieder asked to include
> upstream changelogs and notes that these are only available from the
> website. Would it be possible to include changelogs in future release
> tarballs?

Yes, that possible. I'll make the changelog part of the HTML version of the manual.

> 
> The current way of shipping jquery in Doxygen poses a set of problems
> (mainly http://bugs.debian.org/625956) to Debian. In order to ship a
> package in the Debian main distribution the source code must be
> available in preferred form for modification. This is not the case with
> the version of jquery embedded in Doxygen tarballs, because they are
> minified. Would it be possible to additionally ship the original
> uncompressed javascript components in future release tarballs even if
> they are not used for building Doxygen?

Yes, I've compiled a package (see attachment) which I plan to include 
in the next release. It includes the non-minified scripts and a Makefile to 
compile them into the minified files that in turn can be compiled into doxygen.
Let me know if this meets the requirements. This approach also makes it 
relatively simple to try out newer versions of the scripts.

[Doxygen-develop] release tarballs

[Helmut G. <he...@su...>]

Dear Doxygen developers,

I am writing to you on behalf of the Debian project. There are a few
issues with the doxygen package as shipped by Debian that are imho best
addressed upstream. Please have a look at whether this is reasonable.

In http://bugs.debian.org/569504 Jonathan Nieder asked to include
upstream changelogs and notes that these are only available from the
website. Would it be possible to include changelogs in future release
tarballs?

The current way of shipping jquery in Doxygen poses a set of problems
(mainly http://bugs.debian.org/625956) to Debian. In order to ship a
package in the Debian main distribution the source code must be
available in preferred form for modification. This is not the case with
the version of jquery embedded in Doxygen tarballs, because they are
minified. Would it be possible to additionally ship the original
uncompressed javascript components in future release tarballs even if
they are not used for building Doxygen?

(Moving to wishlist stuff.)

In addition it would be great to be able to use the system version
jquery instead of Doxygen's copy. It is not clear how to achieve this in
a way, that does not pose unreasonable burden on either upstream or the
Debian packaging. Discussion on this issue has started on
http://bugs.debian.org/630982 but has not come to a final conclusion.
The question relevant here appears to be whether Doxygen upstream could
document which versions of jquery (+ components) it needs to work
properly.

It would be interesting to know whether the javascript components, style
sheets and icons shipped with one version of Doxygen could be used with
an older version of Doxygen (possibly broken with major releases). That
would allow us to move them to a package shared among documentation
packages instead of having about 100 packages contain these copies. To
get a rough idea on how many copies we currently ship, have a look at
just the copies of the latest (packaged) version of doxygen.css:
http://dedup.debian.net/hash/sha512/d43d1384010e768003ad5784c9a6af464046871f194dd069b7276aa06c9d96f5dbb9d6bc1faabe836c7713de9db31c54332803986d018f84c0856b410c597f74

Thanks for considering

Helmut

[Doxygen-develop] VHDL package record member documentation broken since 1.7.5 (?)

[Florian M. <Flo...@Be...>]

Hello doxygen developers,

this relates to the observation of another user:
http://doxygen.10944.n7.nabble.com/VHDL-and-packages-tp5078.html

When using doxygen 1.7.4 with VHDL record types defined inside packages, the
individual members documented by a --! string each worked fine and showed up
in the resulting HTML:

classtest__p___174.html
<http://doxygen.10944.n7.nabble.com/file/n5835/classtest__p___174.html>  

With the recent version (and probably some of the other versions in between,
the 1.7.5 in the title is just a presumption), the member documentation
strings do not end up in the doxygen output. Even worse, they influence the
documentation value of types defined after the first type which had record
members documented:
classtest__p___1831.html
<http://doxygen.10944.n7.nabble.com/file/n5835/classtest__p___1831.html>  

This is the example VHDL package to reproduce the problem.
test_p.vhd <http://doxygen.10944.n7.nabble.com/file/n5835/test_p.vhd>  

Regards,
Florian




--
View this message in context: http://doxygen.10944.n7.nabble.com/VHDL-package-record-member-documentation-broken-since-1-7-5-tp5835.html
Sent from the Doxygen - Development mailing list archive at Nabble.com.

Re: [Doxygen-develop] Feature request: color coded comments in source browser

[Michael S. <mi...@st...>]

Dimitri,

Thanks for taking the time to respond.  Yes, I mean to *keep* the markup
commands, preserving the original source file as it was written.  Indeed,
like Eclipse or Notepad++.

We use the doxygen in a few ways.  One for high level overview of structure
for the code, something non-software people can look at.  The other is for
the purpose of peer review code; using STRIP_CODE_COMMENT=NO allow the
markup usage to be reviewed too (learn from and/or critic).  The added
color would help reading source view, catch errors*, and clarify how
Doxygen interprets the markup.

(*the warning file catches errors anyway, so somewhat redundant.)


Thanks again,
Michael


On 1 April 2013 22:47, Doxygen [via Doxygen] <
ml-...@n7...> wrote:

> Hi Michael,
>
> On Mar 29, 2013, at 4:13 , Michael Stangeland <[hidden email]<http://user/SendEmail.jtp?type=node&node=5815&i=0>>
> wrote:
>
> > Eclipse and Notepad++ interpret the comment sections nicely with
> colorized
> > keywords, and a different color for normal comments verses Doxygen
> markup
> > comments.  But when looking at the source the Doxygen markup is now
> harder
> > to read.  (I use STRIP_CODE_COMMENTS=NO because I write minimal comments
> and
> > what little I do write,  I still want to see it)
> >
> > When generating the source code view, would it be possible to add a few
> more
> > styles for the elements inside the comment sections?  I figure the
> parser
> > already identifies the them.  Moreover, this would help understand how
> the
> > parser is using the markup.
> >
> > In the CSS file I found how to change the style, but obviously only one
> > style for all comments.
> >
> > span.comment {
> > color: #800000
> > }
> >
> > I propose:
> > "comment" for normal comments.
> > "docomment" for general Doxygen
> > "dockeyword" or "docommand" for interpreted Doxygen commands (assuming
> the
> > same engine used to interpret the markup, ALIASes would also be
> identified
> > automatically).
> >
> > The extra nice to have would be to also identify and colorize the parsed
> > components of the commands such as <name>.  Also Bold, italic and other
> > formatting could be reflected.
> >
> > Maybe going too far... but the source markup that produces links could
> also
> > be clickable.
>
> Then why not go one step further and let doxygen render the special
> comments
> as it does for the documentation?
>
> Then you could have a documentation view with inline code (when
> INLINE_SOURCES=YES)
> and the inverse; a source view with inline documentation
> (when SOURCE_BROWSER=YES and STRIP_CODE_COMMENTS=NO)
>
> Or do you really want to see the markup commands in the source view, like
> you
> would in Eclipse or Notepad++?
>
> Regards,
>   Dimitri
>
>
>
> ------------------------------------------------------------------------------
>
> Own the Future-Intel&reg; Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> Doxygen-develop mailing list
> [hidden email] <http://user/SendEmail.jtp?type=node&node=5815&i=1>
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>
>
> ------------------------------
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://doxygen.10944.n7.nabble.com/Feature-request-color-coded-comments-in-source-browser-tp5812p5815.html
>  To unsubscribe from Feature request: color coded comments in source
> browser, click here<http://doxygen.10944.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5812&code=bWljaGFlbEBzdGFuZ2VsYW5kLmNhfDU4MTJ8LTI4OTk1Mjc2OA==>
> .
> NAML<http://doxygen.10944.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://doxygen.10944.n7.nabble.com/Feature-request-color-coded-comments-in-source-browser-tp5812p5819.html
Sent from the Doxygen - Development mailing list archive at Nabble.com.

Re: [Doxygen-develop] [PATCH] Improved support for linking to template specializations

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

Hi David,

On Mar 26, 2013, at 23:43 , David Haney <Dav...@ro...> wrote:

> I’ve been looking into the linking issues reported in https://bugzilla.gnome.org/show_bug.cgi?id=619790 related to creating links to template specializations, and I think I have a patch that should address that issue (and some related issues with linking template specializations). I’ve attached a diff and the test case I was using to verify the changes. Please take a look and let me know if this is something that could be incorporated or if you need any additional information from me.
>  

Thanks, looks useful. I'll include your patch.

Regards,
  Dimitri

Re: [Doxygen-develop] Feature request: color coded comments in source browser

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

Hi Michael,

On Mar 29, 2013, at 4:13 , Michael Stangeland <mi...@st...> wrote:
> Eclipse and Notepad++ interpret the comment sections nicely with colorized
> keywords, and a different color for normal comments verses Doxygen markup
> comments.  But when looking at the source the Doxygen markup is now harder
> to read.  (I use STRIP_CODE_COMMENTS=NO because I write minimal comments and
> what little I do write,  I still want to see it)
> 
> When generating the source code view, would it be possible to add a few more
> styles for the elements inside the comment sections?  I figure the parser
> already identifies the them.  Moreover, this would help understand how the
> parser is using the markup.
> 
> In the CSS file I found how to change the style, but obviously only one
> style for all comments.
> 
> span.comment {
> 	color: #800000
> }
> 
> I propose:
> "comment" for normal comments.
> "docomment" for general Doxygen
> "dockeyword" or "docommand" for interpreted Doxygen commands (assuming the
> same engine used to interpret the markup, ALIASes would also be identified
> automatically).
> 
> The extra nice to have would be to also identify and colorize the parsed
> components of the commands such as <name>.  Also Bold, italic and other
> formatting could be reflected.
> 
> Maybe going too far... but the source markup that produces links could also
> be clickable.

Then why not go one step further and let doxygen render the special comments
as it does for the documentation?

Then you could have a documentation view with inline code (when INLINE_SOURCES=YES)
and the inverse; a source view with inline documentation 
(when SOURCE_BROWSER=YES and STRIP_CODE_COMMENTS=NO)

Or do you really want to see the markup commands in the source view, like you
would in Eclipse or Notepad++?

Regards,
  Dimitri

Re: [Doxygen-develop] Too small line height in CSS for headings

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

On Mar 21, 2013, at 16:53 , Vaclav Petras <wen...@gm...> wrote:

> Hi,
> 
> h1 and other h elements have to small line-height. When the heading is
> long and the page is not wide enough, the heading is split into two
> lines, then you can see that heading lines overlaps.
> 
> The line-height reported by Firefox and Chromium is 19px which is at
> the beginning of of doxygen.css:
> 
> body, table, div, p, dl {
> 	font: 400 14px/19px Roboto,sans-serif;
> }
> 
> Sorry for not proving a patch but my CSS knowledge is very limited.

Can you test how far you have to increase the 19px in order to make the
overlapping disappear? I've now set it to 22px.

Regards,
  Dimitri

[Doxygen-develop] Feature request: color coded comments in source browser

[Michael S. <mi...@st...>]

Eclipse and Notepad++ interpret the comment sections nicely with colorized
keywords, and a different color for normal comments verses Doxygen markup
comments.  But when looking at the source the Doxygen markup is now harder
to read.  (I use STRIP_CODE_COMMENTS=NO because I write minimal comments and
what little I do write,  I still want to see it)

When generating the source code view, would it be possible to add a few more
styles for the elements inside the comment sections?  I figure the parser
already identifies the them.  Moreover, this would help understand how the
parser is using the markup.

In the CSS file I found how to change the style, but obviously only one
style for all comments.

span.comment {
	color: #800000
}

I propose:
"comment" for normal comments.
"docomment" for general Doxygen
"dockeyword" or "docommand" for interpreted Doxygen commands (assuming the
same engine used to interpret the markup, ALIASes would also be identified
automatically).

The extra nice to have would be to also identify and colorize the parsed
components of the commands such as <name>.  Also Bold, italic and other
formatting could be reflected.

Maybe going too far... but the source markup that produces links could also
be clickable.





--
View this message in context: http://doxygen.10944.n7.nabble.com/Feature-request-color-coded-comments-in-source-browser-tp5812.html
Sent from the Doxygen - Development mailing list archive at Nabble.com.

[Doxygen-develop] new releases of Moritz 2 an MuLanPa

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

Hello Everybody

I have posted new releases of Moritz 2 an MuLanPa
 Moritz       1.9.07   :      http://sourceforge.net/projects/moritz/ 
 MuLanPa 0.09.02  :     http://sourceforge.net/projects/mulanpa/

  1. The most important change is the fact that as parser-Library
     spirit 2.5.2 (now part of boost 1.52.0) or higher is used now
     instead of spirit 1.8.5. I have compiled the current binaries
     against boost 1.53.0 what seems to be the latest version today.
     This means for you, that you have to download the current
     boost-archive from www.boost.org. This is a really huge thing and
     it may take several minutes to unpack it (use your lunch-time for
     that and take a longer walk after its end). Once you have
     downloaded the new sources of Moritz and MuLanPa, you should be
     able to compile them if you use the root-folder of the unpacked
     boost-archive as search-path.

  2. To reduce the amount of sources the content of "notation_log.h"
     was moved into the files "notation.h" and "notation.cpp". Thus the
     missing file "notation_log.h" in the source-zip should not cause
     problems any more.

  3. In the current releases you will find my tinyxml-sources also thus
     I hope my small change will be no problem any more also.

I decided to have this release now to support those users who want to 
help me as beta-testers or who want to use Moritz2 for their own 
developments. The new functionality for the end-users may not be 
essential. But for the further development it is very important to get 
some feedback. So please check it out and use the new development-forum 
of this project to discuss problems and feature-requests and use the 
help-forum to discuss the usage of already existing features.


Best regards and happy eastern,
                                                  Eckard Klotz.

Re: [Doxygen-develop] Bug 696413: \ref does not work for C++11 using typedefs

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

Ok.  Thanks David.

 From this point on, I am leaving the rest of this problem to Dimitri.
Although I have permissions to edit the bug, the bug may require a lot
of work to resolve.  Dimitri can set the HELPWANTED keyword on the bug
if he does not have the time to fix it himself.

Kevin McBride
dol...@ai...


-----Original Message-----
From: David Haney <Dav...@ro...>
To: Kevin McBride <dol...@ai...>; doxygen-develop 
<dox...@li...>
Sent: Mon, Mar 25, 2013 6:26 pm
Subject: RE: [Doxygen-develop] Bug 696413: \ref does not work for C++11 
using	typedefs

This bug appears to be referring to a C++11 alias-declaration:

alias-declaration:
	using identifier attribute-specifier-seqopt = type-id ;

See section 7.1.3 p2 of 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf.

David.

-----Original Message-----
From: Kevin McBride [mailto:dol...@ai...]
Sent: Monday, March 25, 2013 2:43 PM
To: dox...@li...
Subject: [Doxygen-develop] Bug 696413: \ref does not work for C++11 
using typedefs

The following bug has a claim to a new C++11 extension.  I spoke with
an instructor and a tutor on the extension, and they think the
extension shown on the bug does not exist.

I also tried looking it up on cplusplus.com, and can not find the
extension.

Unless someone knows that the extension exists, I think the bug should
be marked as "NEEDINFO" to ask where the extension comes from, or
"RESOLVED - INVALID" if the decision will be the same as made by three
people, including myself.

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

Kevin McBride
dol...@ai...



-------------------------------------------------------------------------
-----
Own the Future-Intel&reg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
Doxygen-develop mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-develop

Re: [Doxygen-develop] Bug 696413: \ref does not work for C++11 using typedefs

[David H. <Dav...@ro...>]

This bug appears to be referring to a C++11 alias-declaration: 

alias-declaration:
	using identifier attribute-specifier-seqopt = type-id ;

See section 7.1.3 p2 of http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf.

David.

-----Original Message-----
From: Kevin McBride [mailto:dol...@ai...] 
Sent: Monday, March 25, 2013 2:43 PM
To: dox...@li...
Subject: [Doxygen-develop] Bug 696413: \ref does not work for C++11 using typedefs

The following bug has a claim to a new C++11 extension.  I spoke with 
an instructor and a tutor on the extension, and they think the 
extension shown on the bug does not exist.

I also tried looking it up on cplusplus.com, and can not find the 
extension.

Unless someone knows that the extension exists, I think the bug should 
be marked as "NEEDINFO" to ask where the extension comes from, or 
"RESOLVED - INVALID" if the decision will be the same as made by three 
people, including myself.

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

Kevin McBride
dol...@ai...



------------------------------------------------------------------------------
Own the Future-Intel® Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________
Doxygen-develop mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] Bug 696413: \ref does not work for C++11 using typedefs

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

The following bug has a claim to a new C++11 extension.  I spoke with 
an instructor and a tutor on the extension, and they think the 
extension shown on the bug does not exist.

I also tried looking it up on cplusplus.com, and can not find the 
extension.

Unless someone knows that the extension exists, I think the bug should 
be marked as "NEEDINFO" to ask where the extension comes from, or 
"RESOLVED - INVALID" if the decision will be the same as made by three 
people, including myself.

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

Kevin McBride
dol...@ai...

Re: [Doxygen-develop] [PATCH] UNO IDL language support

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

Hi Michael,

Thanks for your contribution.

Could you collapse the UNO IDL related patches into one big patch that
applies against SVH head (which has just been updated)? That makes it
a bit easier for me to apply the patch.

Regards,
  Dimitri

(I agree that Entry::spec should be split into a member and a class field).

On Mar 22, 2013, at 22:14 , Michael Stahl <ms...@re...> wrote:

> 
> hi all,
> 
> the LibreOffice project wants to exit the source code documentation tool
> market, and instead use doxygen  :)
> 
> we already use doxygen to generate the C++ documentation for the SDK
> since the 3.5 release.
> 
> unfortunately the bulk of the documentation is currently still generated
> with the legacy "autodoc" tool inherited from OpenOffice.org, because it
> is the only tool that can parse UNO IDL files.
> 
> but not any more!  with the attached patches doxygen learns a few new
> tricks and can understand UNO IDL too.
> 
> the only bits missing are "unions" which look differently than in other
> languages and some "needs"/"observes" stuff; these things are not used
> at all in the LibreOffice API so i won't implement them (and am
> considering removing them from our IDL compiler).
> 
> this builds on Linux x86_64 with GCC 4.7 and Windows with MSVC 2008 and
> cygwin GCC 3.4.
> 
> hope it doesn't break anything (but i didn't test anything other than
> UNO IDL -> HTML).
> 
> one particularly annoying problem i had to work around several times is
> that Entry::spec contains values from both MemberSpecifier and
> ClassSpecifier which both define same values, causing spurious tags to
> appear in the output.
> 
> of course all patches are licensed under standard license of doxygen
> project which i assume is GPL.
> 
> regards,
> michael
> 
> 
> <0001-add-.gitignore.patch><0002-Windows-calls-snprintf-_snprintf.patch><0003-UNO-IDL-add-service-as-new-compound.patch><0004-UNO-IDL-add-interface-members-for-services.patch><0005-UNO-IDL-add-optional-keyword-on-interface-members.patch><0006-UNO-IDL-add-singleton-as-new-compound.patch><0007-UNO-IDL-add-service-members-for-services-and-singlet.patch><0008-UNO-IDL-everything-is-public.patch><0009-IDL-fix-spurious-Final-tag-on-exceptions.patch><0010-UNO-IDL-add-attribute-members.patch><0011-UNO-IDL-add-property-members.patch><0012-enum-MemberSpecifier-is-full.patch><0013-UNO-IDL-add-sundry-attribute-property-modifiers.patch><0014-UNO-IDL-support-published-keyword-on-compounds.patch><0015-UNO-IDL-add-inheritance-relation-for-interface-servi.patch><0016-UNO-IDL-add-constants-constant-group-support.patch><0017-UNO-IDL-published-on-constant-groups.patch><0018-improve-the-HTML-output-for-exception-specifications.patch><0019-MSVC-2008-does-not-do-64-bit-enum-values.patch><0020-UNO-IDL-add-translation-adapters-to-build-without-en.patch><0021-UNO-IDL-fix-parsing-problem-with-interface-members.patch>

[Doxygen-develop] Too small line height in CSS for headings

[Vaclav P. <wen...@gm...>]

Hi,

h1 and other h elements have to small line-height. When the heading is
long and the page is not wide enough, the heading is split into two
lines, then you can see that heading lines overlaps.

The line-height reported by Firefox and Chromium is 19px which is at
the beginning of of doxygen.css:

body, table, div, p, dl {
	font: 400 14px/19px Roboto,sans-serif;
}

Sorry for not proving a patch but my CSS knowledge is very limited.

Using Doxygen 1.8.3.1-20130209.

Vaclav

[Doxygen-develop] Cannot get the correct informaition from the interfaces of 'IDocCodeLine'

[Qiuping Yi <yiq...@gm...>]

Dear all,

I am a doxygen user.

I want to use doxygen's doxmlparser to analysis the generated xml files
from C code. When I use the next code the print the line number and ref
information for each C code line:

if (comp->kind() == ICompound::File) {
            IFile *file = dynamic_cast<IFile*>(comp);
            IDoc *source = file->source();
            IDocProgramListing *programListing =
dynamic_cast<IDocProgramListing*>(source);
            IDocIterator *cli = programListing->codeLines();
            IDoc *cx;
            for (cli->toFirst();(cx=cli->current());cli->toNext()) {
                IDocCodeLine *cl = dynamic_cast<IDocCodeLine*>(cx);
                ASSERT(cl!=0);
                printf("<codeline lineNumber=%d
refId=`%s'>\n",cl->lineNumber(),cl->refId()->latin1());
            }
        }
}

I can only get the next *"empty"* information. What's wrong of my code? Did
I miss something? Thank you all in advance.

<codeline lineNumber=0 refId=`'>
<codeline lineNumber=0 refId=`'>
<codeline lineNumber=0 refId=`'>
<codeline lineNumber=0 refId=`'>
<codeline lineNumber=0 refId=`'>
<codeline lineNumber=0 refId=`'>
<codeline lineNumber=0 refId=`'>
<codeline lineNumber=0 refId=`'>
<codeline lineNumber=0 refId=`'>
<codeline lineNumber=0 refId=`'>
<codeline lineNumber=0 refId=`'>
...
...


--------------------------------------------
Qiuping Yi
Institute Of Software
Chinese Academy of Sciences