doxygen-users — List for users of doxygen

Re: [Doxygen-users] RE: Emails from two doxygen mailing lists...

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

On Fri, May 04, 2001 at 03:03:25PM -0400, Don McClimans wrote:
> I think we're supposed to be using the new one. I believe Dimitri has
> already said he will eventually shut down the old one.

XeT is the owner of the old list, so he decides how long the old
list will remain alive. But it will disappear, so I strongly suggest to use
the new list.

> Certainly those of us who want to use the digest feature would appreciate
> everyone moving to the SourceForge list. :)

That too is a nice bonus.

Regards,
  Dimitri

Re: [Doxygen-users] Doyxgen 1.2.7: \ingroup group1 group2 still allowed?

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

On Fri, May 04, 2001 at 03:12:54PM +0200, Patrick Ohly wrote:
> Hi all!
> 
> According to the documentation (and implementation) of
> \ingroup an entity may be put into several different
> groups at once.

Yes, but...

> 
> However, later on in groupdef.cpp:addMemberToGroups()
> this is detected and triggers a warning (groupdef.cpp, line 617):
> 
>   Member ... found in multiple groups.!
>   The member will be put in group ..., and not group ...
> 
> The class MemberDef also allows to set only one GroupDef: 
>     setGroupDef(GroupDef *gd)        { group=gd; }

... members are an exception. Anything else can be in multiple groups.

> Are \ingroup and related mechanisms with more than one
> group per entity deprecated? 

No, but for members there is a slight problem.
Currently, a member is identified by its container and a local label
unique within the container (in html: a file and an anchor). 

Now suppose a member is in two groups and we want to (auto)link to it.
Where should the link go to?

A clean solution would be to link to the natural container of the
member (i.e. for a global function link to the file, for a class
member link to the class), regardless of any artifical group the 
member was put in.

But then what if someone wants its documentation to consist just of
the items that he/she grouped by hand? This would lead to ambigious
links targets in case the member is in multiple groups.

> If you ask me, then I'd be more than happy when each
> entity can only be in one group and I'd volunteer to
> clean up the implementation: 
> 
> - Entry::groups doesn't have to be a list.

It still does for entries that do not represent members.

> - An explicit \ingroup overrides an implicit @{ @}.

That would make sense.

> - A \defgroup @{ @} in one place overrides an \addtogroup @{ @}
>   in another place (e.g. header files uses \defgroup, C files use
>   \addtogroup) - this is currently impossible to implement, but
>   something that I have been missing for quite a while.

Well if it is impossible to implement, then feel free to try
the impossible :-)

Regards,
  Dimitri

[Doxygen-users] RE: Emails from two doxygen mailing lists...

[Don M. <dmc...@In...>]

I think we're supposed to be using the new one. I believe Dimitri has
already said he will eventually shut down the old one.

Certainly those of us who want to use the digest feature would appreciate
everyone moving to the SourceForge list. :)

Don


-----Original Message-----
From: Catenacci, Onorio [mailto:Ono...@co...]
Sent: Friday, May 04, 2001 1:03 PM
To: dox...@li...; do...@xe...
Subject: Emails from two doxygen mailing lists...


Hi all,

I keep receiving mail from both the old doxygen mailing list and the new
one.  So I'm motivated to ask:

1.) Are we supposed to be using the old mailing list, the new one or does it
matter?

2.) Is the old mailing list scheduled to be shut down at some point in the
future?

--
Onorio Catenacci

RE: [Doxygen-users] Again about translations...

[Alessandro F. <afa...@da...>]

Hi Petr,

...
> As you adviced, the approach like this...
>
> >  QCString trMemberList(const QCString& className)
>
> ...is the right way.

Glad to hear you agree.

...
> In other words, changing the trMemberList() and similar
> to take some arguments will affect the core code, but
> will not break the other maintainers work, nor require from
> them any effort until they decide to update their translator.
> [ This means that the changes will be less painful (for
> Dimitri and others) and the development here can be
> more rapid (because of avoiding dependency on
> the language maintainers). ]

I think changing the core code would be undoubtedly painful, but there
should be a strong motivation in the change too.

> So, the main problem is to find, where the old method
> was called and think deeply whether newly proposed
> method will not create some apparent obstacles in future.

That's the hardest part cause you must grant sufficient flexibility to guard
against every possible future requirement (or at least try to satisfy a
large class of them) without even imagining it.

> Once this is decided, Dimitri (or someone closely
> cooperating with him) can change the interface of
> the decided method and create its appropriate
> default implementation in the adapter class which
> takes advantage of the older method, which
> already gives translated string or substring.

Agreed.

> The maintainters could always look inside a documentation
> whether their implementation is up-to-date or should
> be updated.  (This was not released yet, but the
> perl script for generating the documentation will probably
> be released soon.)

Yes, the latest deep changes in 1.2.7 forced me to a complete revision.

> There already are examples of the changed interface
> in the last CVS releases.  You may have a look at
> trFiles() which was totally replaced by trFile(params).
> There also are good candidates to use exactly the same
> approach, like trAuthors() and trAuthor() -- not done yet.

I'll look closer at it

> Conclusion: Let's start discussing the changes and
> select the first candidates.

I haven't the source handy, but from memory I cite those tr functions which
produce section titles containing entity names (e.g.class or struct names).
More to come.

Alessandro

[Doxygen-users] Emails from two doxygen mailing lists...

[Catenacci, O. <Ono...@co...>]

Hi all,

I keep receiving mail from both the old doxygen mailing list and the new
one.  So I'm motivated to ask:

1.) Are we supposed to be using the old mailing list, the new one or does it
matter?

2.) Is the old mailing list scheduled to be shut down at some point in the
future?

--
Onorio Catenacci

"Assiduous and frequent questioning is indeed the first key to wisdom...for
by doubting we come to inquiry; through inquiring we perceive the truth ..."

--Peter Abelard, "Sic et Non"

[Doxygen-users] Re: Doyxgen 1.2.7: \ingroup group1 group2 still allowed?

[Guntram B. <be...@Ma...>]

Patrick Ohly wrote:
Patrick Ohly wrote:

>=20
> If you ask me, then I'd be more than happy when each
> entity can only be in one group and I'd volunteer to
> clean up the implementation:

I think it can make sense to have one entity in several
groups, and would therefore strongly advocate that this
will remain an option.
I could however imagine a config option which triggers warnings
if an entity is in several groups, in circumstances where this
is considered an error.

cheers
--guntram


--=20
------------------------------------------------------------------
Dr. Guntram Berti            | voice: ++49 +355 69 37 17
                             | fax  : ++49 +355 69 24 02
LS  Numerische Mathematik &  | be...@ma...
 Wissenschaftliches Rechnen  | http://www.math.tu-cottbus.de/~berti
Institut f=FCr Mathematik      |                     =20
BTU Cottbus                  | R 313,                  O__ =20
Universit=E4tsplatz 3-4        | Lehrgeb=E4ude 1          c/ /'_
D-03044 Cottbus              |                       (*) \(*)=20
------------------------------------------------------------------

[Doxygen-users] enable preprocessing in 1.2.6

[Emanuele O. <oli...@it...>]

Hi,
I generated doxygen documentation with

INLINE_SOURCES         = YES
ENABLE_PREPROCESSING   = YES
MACRO_EXPANSION        = NO

and I got inline sources not preprocessed. But I'd like to have them
processed. 
Is it a correct result?
Is it possible to have inline sources pre-processed?

Thanks in advance,

					Emanuele
					Olivetti

[Doxygen-users] Doyxgen 1.2.7: \ingroup group1 group2 still allowed?

[Patrick O. <Pat...@pa...>]

Hi all!

According to the documentation (and implementation) of
\ingroup an entity may be put into several different
groups at once.

However, later on in groupdef.cpp:addMemberToGroups()
this is detected and triggers a warning (groupdef.cpp, line 617):

  Member ... found in multiple groups.!
  The member will be put in group ..., and not group ...

The class MemberDef also allows to set only one GroupDef: 
    setGroupDef(GroupDef *gd)        { group=gd; }

Are \ingroup and related mechanisms with more than one
group per entity deprecated? 

If you ask me, then I'd be more than happy when each
entity can only be in one group and I'd volunteer to
clean up the implementation: 

- Entry::groups doesn't have to be a list.
- An explicit \ingroup overrides an implicit @{ @}.
- A \defgroup @{ @} in one place overrides an \addtogroup @{ @}
  in another place (e.g. header files uses \defgroup, C files use
  \addtogroup) - this is currently impossible to implement, but
  something that I have been missing for quite a while.

Bye, Patrick
-- 
// pallas  GmbH  ............  Patrick Ohly  .............
   Hermuelheimer Str. 10       Software-Engineer
   D-50321 Bruehl, Germany     po...@pa...
   fax +49-(0)2232-1896-29     phone  +49-(0)2232-1896-30 
   http://www.pallas.com 
..........................................................

[Doxygen-users] Bug in grouping function

[Guntram B. <be...@Ma...>]

Hello doxygeners,

I think I have found a bug in doxygen's grouping output:
Doxygen erroneously puts class member functions of a member group
into another group, defined with @defgroup later on:

Consider the following input:

-------
class A {
public:
  //@{ @name group1
  int f();
  //@}

};

/*! @defgroup g2 Group of functions

 */

/*! @ingroup g2

 */
void fun1();
--------

This leads to the output (group__g2.html):


---------
       Group of functions


Functions

   int=20
      f ()  =20
      ^^^^^^^ NOT IN GROUP g2!
   void=20
      fun1 ()
----------



The error occurs with both doxygen 1.2.7 and 1.2.5,
and also if class A is defined in a separate file.

cheers
--guntram


--=20
------------------------------------------------------------------
Dr. Guntram Berti            | voice: ++49 +355 69 37 17
                             | fax  : ++49 +355 69 24 02
LS  Numerische Mathematik &  | be...@ma...
 Wissenschaftliches Rechnen  | http://www.math.tu-cottbus.de/~berti
Institut f=FCr Mathematik      |                     =20
BTU Cottbus                  | R 313,                  O__ =20
Universit=E4tsplatz 3-4        | Lehrgeb=E4ude 1          c/ /'_
D-03044 Cottbus              |                       (*) \(*)=20
------------------------------------------------------------------

[Doxygen-users] Template problem

[Ren G. <r.g...@ca...>]

Hi !

I have a problem in the following example.
Example:

template <typename XYZ >
class ABC : virtual public XYZ { };

Problem:

I have a class template that is derived from its template parameter "XYZ".
Doxygen makes an error and recognizes the 'XYZ' parameter as a real known
class. That's wrong because 'XYZ' is a wild card - only after the object of
ABC type is created the type of the template will be known.
Therefore it would be better, if Doxygen omits the documentation of the
template parameter 'XYZ '.

MfG
Ren=E9

RE: [Doxygen-users] Again about translations...

[Prikryl,Petr <PRI...@sk...>]

Hi Alessandro,

Alessandro Falappa wrote...
> [...] italian doesn't have a saxon genitive form.
> [...] Many section titles in the documentation generated 
> by Doxygen adopt the saxon genitive form: in a project
> called Foobar we have "Foobar Documentation" [...]

This is also the Czech language problem.  I had a disussion with
Dimitri earlier.  The conclusion was that there is no
general way how to put translated pieces of text together
so that well looking sentence is produced for all languages.

The only solution is to have trXxxx() with all the 
parameters necessary for composition of a meaningful
sentence.  Then the language maintainer is responsible
for puting the things together -- possibly using results
of other translator methods for generating the pieces.

As you adviced, the approach like this...

>  QCString trMemberList(const QCString& className)

...is the right way.

Fortunately, the new internal mechanism for deriving
national translators was introduced with doxygen 1.2.7.
It uses adapter classes that allow change the interface of 
the Translator class and still preserve the functionality 
of older TranslatorXxxx classes for the Xxxx language.

In other words, changing the trMemberList() and similar
to take some arguments will affect the core code, but 
will not break the other maintainers work, nor require from 
them any effort until they decide to update their translator.
[ This means that the changes will be less painful (for 
Dimitri and others) and the development here can be 
more rapid (because of avoiding dependency on
the language maintainers). ]

The method can even change the name.  Some other
argument can also signalize that the translation should
have some special form like:

 1) for the HTML head title
     "Project, version, class: Member List"

  2) for HTML page heading (i.e. on the page)
     "Member List for class"
  
etc.

So, the main problem is to find, where the old method
was called and think deeply whether newly proposed
method will not create some apparent obstacles in future.

Once this is decided, Dimitri (or someone closely 
cooperating with him) can change the interface of 
the decided method and create its appropriate 
default implementation in the adapter class which
takes advantage of the older method, which
already gives translated string or substring.

The maintainters could always look inside a documentation
whether their implementation is up-to-date or should
be updated.  (This was not released yet, but the 
perl script for generating the documentation will probably
be released soon.)

There already are examples of the changed interface
in the last CVS releases.  You may have a look at
trFiles() which was totally replaced by trFile(params).
There also are good candidates to use exactly the same
approach, like trAuthors() and trAuthor() -- not done yet.

Conclusion: Let's start discussing the changes and 
select the first candidates.

Petr
 
-- 
Petr Prikryl, SKIL, spol. s r.o., pri...@sk...

[Doxygen-users] Again about translations...

[Alessandro F. <afa...@da...>]

Hi all,
while revising the italian translation I re-noticed a fact: italian doesn't
have a saxon genitive form.

It may be silly to discover an obvious (for me) situation but this fact has
several implications.

Many section titles in the documentation generated by Doxygen adopt the
saxon genitive form: in a project called Foobar we have "Foobar
Documentation" while for a class called Base we have "Base Class
Documentation", "Base Class Member List" and so on.

The equivalent italian translation obtained preserving the above order (name
of the entity then translated string) sounds a bit strange. The correct
order for the italian language is the one which corresponds to
"Documentation of Class Foobar", "List of Members of Class Base" and so on.

A possible but code-breaking solution is to give complete freedom to the
translator by passing an argument to the title translating function
representing the name of the entity, for example:

QCString trMemberList(const QCString& className)

which should return the title of the member list of the class named
<className>.

If, as I suppose, the title is generated calling more than one translation
function (as in those title wich differ by the entity type as in: "Base
Class Member List", "Base Enum Member List", "Base Struct Member List" etc.)
the ideal solution whould be something like the existing function:

QCString trCompoundReference(const char *clName,
                             ClassDef::CompoundType compType,
                             bool isTemplate)

What do other language maintaner and Dimitri think?

Alessandro Falappa

[Doxygen-users] best way to doc inputs to functions that are not params?

[Jake K. <jk...@bi...>]

What's the best way to doc inputs to functions that are not function
parameters?
There is no @in command for describing these interfaces.

i.e.  a function has params, but as input uses a private class member or
other classes as an input.

I am currently used to documenting my code this way:

/**
* function description...
* in:    params, other member inputs m_* that are not params, could be
objects or data,
*        in this case it's a class member m_nMultiplier, but could be
another object.
* out:  (similar to @return), in this case the function return value.
* pre:    object state expectation that this function expects, in this
case:
* pre:    m_nMultiplier is assumed to be initialized to a valid
state/range.
* post:  an object/program state condition that exist after function is
called).  In this case
*        none.
*/
int MyClass::foo( int param1)
{
    return this->m_nMultiplier * param1;
}

Using dxoygen I can convert everything but inputs, what do people use in
this case?
/**
* function description...
* in:  (params, other member inputs m_* that are not params, could be
objects or data)
* @return:    (similar to post, but usually uses for class members)
* @pre    (object state expectation)
* @post  (more of an object state condition).
*/

RE: [Doxygen-users] Mailing list reply address

[Don M. <dmc...@In...>]

>The MailMan program (which is used by SourceForge) has an option to
>delay incoming mails to prevent auto-reply-flooding. Also, MailMan is
>smart enough to filter a lot of things out that aren't supposed to go
>to the list, including commands like Unsubscribe, and (possibly, I'm
>not sure of this), mails that already have been sent (e.g. auto-respond
>replies).

If the sourceForge mailer is smart enough to deal with auto-responders, then
I agree it is much more convenient to have the reply button send to the
list.

I don't really know much about mailing lists, but I just went to the mailman
home page (www.list.org), and one of the features listed is "Integrated
bounce detection within an extensible framework. Automatic disposition of
bouncing addresses (disable, unsubscribe)". So it sounds like it's taken
care of. Until proven otherwise, I retract my previous suggestion, and
instead suggest we leave it as Dimitri just set it, to reply to the list.

Though you might want to dig around in the list admin options, Dimitri, and
see if there is something that has to be turned on to enable this.

Don

Re: [Doxygen-users] Mailing list reply address

[Jac G. <ja...@ma...>]

>>Last note: xteq mailing list was set up to allow to reply directly to 
the
>>mailing list. doxygen-users ML is set up for replying to the 
originator of
>the
>>message. I believe the ML administrator should set the xteq behavior, 
as it
>>is more convenient.
>
>I realize that it is more convenient, but most mailing lists are set 
to
>reply to the originator for a reason. This avoids the problem we often 
have
>on the xteq list of autoresponders flooding the mailing list when 
someone
>goes out of town and forgets that they are on the mailing list.

The MailMan program (which is used by SourceForge) has an option to 
delay incoming mails to prevent auto-reply-flooding. Also, MailMan is 
smart enough to filter a lot of things out that aren't supposed to go 
to the list, including commands like Unsubscribe, and (possibly, I'm 
not sure of this), mails that already have been sent (e.g. auto-respond 
replies). 

The problem as I recall with the old list was many times that 
autoresponders would reply to the sender, not to the list, so the list 
server couldn't adequately react to the autoresponder (e.g. by 
forwarding the mail to the administrator and putting the recipient on 
hold) because it would never get the mail. So setting the reply-to to 
the list addres wouldn't even work for these brain-dead auto-
responders.

Another issue: many times, people simply reply to mails by clicking the 
reply-button. The reply will be sent to the person who asked so she 
will be happy, but she will also get many replies of other people who 
didn't see the first reply. This is a waste of effort for people who 
regularly reply to questions on the mailing list and don't initiate 
many discussions themselves.

Also, on brain-dead mailing clients (like the one I use, I have to 
admit, even though it was written by my own company), there isn't even 
a reply-to-all or reply-to-sender-not-originator button - you have to 
dig through menus to get to it and of course it's easy to forget to do 
so, especially if you're subscribed to multiple mailing lists (like 
me).

In short: I think the old situation was better and reply-to the mailing 
list address should return.

===Jac

Re: [Doxygen-users] Mailing list reply address

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

On Thu, May 03, 2001 at 04:00:17PM -0400, Don McClimans wrote:
> >Last note: xteq mailing list was set up to allow to reply directly to the
> >mailing list. doxygen-users ML is set up for replying to the originator of
> the
> >message. I believe the ML administrator should set the xteq behavior, as it
> >is more convenient.
> 
> I realize that it is more convenient, but most mailing lists are set to
> reply to the originator for a reason. This avoids the problem we often have
> on the xteq list of autoresponders flooding the mailing list when someone
> goes out of town and forgets that they are on the mailing list. I don't know
> if you can change this behavior at SourceForge, but I don't think we
> should - and I urge everyone to not work around this - leave the reply set
> to the originator.

I just changed this the minute before I read your mail :-), but you have a good point. 
Maybe it is better to trade some convenience for less flooding. What do 
you guys think, should reply messages be sent to the poster or to the list?

Regards,
  Dimitri

Re: [Doxygen-users] About Doxygen new language support..

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

On Thu, May 03, 2001 at 10:58:01AM +0200, Philippe Lhoste wrote:
> 
> Last note: xteq mailing list was set up to allow to reply directly to the
> mailing list. doxygen-users ML is set up for replying to the originator of the
> message. I believe the ML administrator should set the xteq behavior, as it
> is more convenient.

I've changed mailman's behaviour to mimic xteq's list more closely. Please let
me know if more changes are desired.

Regards,
  Dimitri

[Doxygen-users] Mailing list reply address

[Don M. <dmc...@In...>]

>Last note: xteq mailing list was set up to allow to reply directly to the
>mailing list. doxygen-users ML is set up for replying to the originator of
the
>message. I believe the ML administrator should set the xteq behavior, as it
>is more convenient.

I realize that it is more convenient, but most mailing lists are set to
reply to the originator for a reason. This avoids the problem we often have
on the xteq list of autoresponders flooding the mailing list when someone
goes out of town and forgets that they are on the mailing list. I don't know
if you can change this behavior at SourceForge, but I don't think we
should - and I urge everyone to not work around this - leave the reply set
to the originator.

RE: [Doxygen-users] About Doxygen new language support..

[Alessandro F. <afa...@da...>]

....
> I may not be the best qualified to answer, but since I have done so lookup
> for a similar question in the Scintilla mailing list, here are my
> conclusions.
> I believe that ansicpg means Ansi Code Page. 1252 is the code page for the
> Ansi character set, ie. the charset that Windows uses for occidental
> (european?) languages.
>
> From the MSDN:
>
> >>>
> The following table shows the correlation of Charset name,
> Charset Value and
> Codepage number:
> Charset Name       Charset Value(hex)  Codepage number
> ------------------------------------------------------
> DEFAULT_CHARSET           1 (x01)
> SYMBOL_CHARSET            2 (x02)
> OEM_CHARSET             255 (xFF)
> ANSI_CHARSET              0 (x00)            1252
> RUSSIAN_CHARSET         204 (xCC)            1251
> EE_CHARSET              238 (xEE)            1250
> GREEK_CHARSET           161 (xA1)            1253
> TURKISH_CHARSET         162 (xA2)            1254
> BALTIC_CHARSET          186 (xBA)            1257
> HEBREW_CHARSET          177 (xB1)            1255
> ARABIC _CHARSET         178 (xB2)            1256
> SHIFTJIS_CHARSET        128 (x80)             932
> HANGEUL_CHARSET         129 (x81)             949
> GB2313_CHARSET          134 (x86)             936
> CHINESEBIG5_CHARSET     136 (x88)             950
> <<<
>
> So this table also explain the charset... BTW, I wonder if fcharset is a
> typo or something I don't know.

Your response answers perfectly to my first question and let me continue in
the translation work!

Anyone about the second question?

> Last note: xteq mailing list was set up to allow to reply directly to the
> mailing list. doxygen-users ML is set up for replying to the
> originator of the
> message. I believe the ML administrator should set the xteq
> behavior, as it
> is more convenient.

I would prefer that behaviour too cause it would make it easier to create a
rule for moving the mailing list messages to a separate mail folder (Yes
seems that Outlook uses the reply to address as the sender address)

Alessandro Falappa

Re: [Doxygen-users] About Doxygen new language support..

[Hendrik S. <do...@HS...>]

"Philippe Lhoste" <Ph...@gm...> wrote:

> [...]
> Last note: xteq mailing list was set up to allow to reply directly to the
> mailing list. doxygen-users ML is set up for replying to the originator of the
> message. I believe the ML administrator should set the xteq behavior, as it
> is more convenient.

  While it might be possible that the ML adds a Reply-To field 
  to every mail (or replaces the one already there), you can 
  always do so by yourself (see my header). 

> Thank you.
> Philippe Lhoste (Paris -- France)

  Schobi

[Doxygen-users] Search button in the tree view

[Holger M. <hmu...@si...>]

Hi doxygen wizards,

can anybody add the the search button within the tree view? I only get it
on the index. I'd like to disable the index, but then I have no search
access. @-)

Many many thanks!
Holger
-- =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Holger M=FCller, Dipl.-Ing.                          Tel: +49/7034/92584-77=

Abt. DOTE - Entwicklung                            Fax: +49/7034/92584-99
sitronic GmbH
Robert-Bosch-Str. 9                          eMail: hmu...@si...
D-71116 Gaertringen                          URL: http://www.sitronic.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

RE: [Doxygen-users] About Doxygen new language support..

[Philippe L. <Ph...@gm...>]

Alessandro Falappa wrote:
> 	while updating the support for the italian language I came 
> across these
> methods regarding the new RTF language code support, I actually 
> do not know
> their meaning, could someone explain it so I can return something
> meaningful?
> 
>     /*! Used as ansicpg for RTF file */ <<<< what's an ansicpg?
>     virtual QCString trRTFansicp()
>     {
>       return "1252"; <<<< which value should return ?
>     }
> 
>     /*! Used as ansicpg for RTF fcharset */
>     virtual QCString trRTFCharSet()
>     {
>       return "0"; <<<< and here?
>     }

I may not be the best qualified to answer, but since I have done so lookup
for a similar question in the Scintilla mailing list, here are my conclusions.
I believe that ansicpg means Ansi Code Page. 1252 is the code page for the
Ansi character set, ie. the charset that Windows uses for occidental
(european?) languages.

From the MSDN:

>>>
The following table shows the correlation of Charset name, Charset Value and
Codepage number:
Charset Name       Charset Value(hex)  Codepage number
------------------------------------------------------
DEFAULT_CHARSET           1 (x01)
SYMBOL_CHARSET            2 (x02)
OEM_CHARSET             255 (xFF)
ANSI_CHARSET              0 (x00)            1252
RUSSIAN_CHARSET         204 (xCC)            1251
EE_CHARSET              238 (xEE)            1250
GREEK_CHARSET           161 (xA1)            1253
TURKISH_CHARSET         162 (xA2)            1254
BALTIC_CHARSET          186 (xBA)            1257
HEBREW_CHARSET          177 (xB1)            1255
ARABIC _CHARSET         178 (xB2)            1256
SHIFTJIS_CHARSET        128 (x80)             932
HANGEUL_CHARSET         129 (x81)             949
GB2313_CHARSET          134 (x86)             936
CHINESEBIG5_CHARSET     136 (x88)             950
<<<

So this table also explain the charset... BTW, I wonder if fcharset is a
typo or something I don't know.

BTW, I saw an advertisement for VIM, so I will plug (again!) an ad for SciTE
(www.Scintilla.org). This text editor (for Windows and GTK+) have a C/C++
lexer (syntax highlighting) where I added different styles for doc. comments
(/** and /*!) and line doc. comments (/// and //!). I didn't get so far as to
colorize the \tag and @tag, but why not?

I also started to doxyfy (? doxygenify?) the comments of the sources of
Scintilla and SciTE, but it is much a work in progress.

Last note: xteq mailing list was set up to allow to reply directly to the
mailing list. doxygen-users ML is set up for replying to the originator of the
message. I believe the ML administrator should set the xteq behavior, as it
is more convenient.

Thank you.

-- 
--._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
--´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`--

Sent through GMX FreeMail - http://www.gmx.net

[Doxygen-users] man output: man pages for documented entities

[Patrick O. <Pat...@pa...>]

Hi,

first of all my thanks to Dimitri for including the man
output patches - a few patches less to be added to
my local doxygen source ;-)

I have been at it again, though. This time I have added
the possibility to generate a man page for any entity
(function, enumeration, enumeration value, etc.) that
is documented. This is configurable and defaults to NO,
so that doxygen behaves the same as before. From the new
config file:

# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
# then it will generate one additional man file for each entity
# documented in the real man page(s). These additional files
# only source the real man page, but without them the man command
# would be unable to find the correct page. The default is NO.

MAN_LINKS              = NO

As usual, patch attached...

Bye, Patrick Ohly
-- 
// pallas  GmbH  ............  Patrick Ohly  .............
   Hermuelheimer Str. 10       Software-Engineer
   D-50321 Bruehl, Germany     po...@pa...
   fax +49-(0)2232-1896-29     phone  +49-(0)2232-1896-30 
   http://www.pallas.com 
..........................................................

[Doxygen-users] About Doxygen new language support..

[Alessandro F. <afa...@da...>]

Hi all,
	while updating the support for the italian language I came across these
methods regarding the new RTF language code support, I actually do not know
their meaning, could someone explain it so I can return something
meaningful?

    /*! Used as ansicpg for RTF file */ <<<< what's an ansicpg?
    virtual QCString trRTFansicp()
    {
      return "1252"; <<<< which value should return ?
    }

    /*! Used as ansicpg for RTF fcharset */
    virtual QCString trRTFCharSet()
    {
      return "0"; <<<< and here?
    }

Second question:
Where is the trGlobal(bool first_capital, bool singular) used?
Is it used as an adjective to construct compound phrases (for example
calling trGlobal and trMember would produce "global member" but not all of
the singular/plural combination make sense)?
Or does it mean global elements of the C++ language (that's those
declaration outside any scope) which appears when one adds a \file comment
in every file?

Thanks
Alessandro Falappa

[Doxygen-users] VIM 5.7: A more complete syntax for doxygen

[Emilio R. <emi...@ma...>]

Hi,
In the attached zip archive you can find a substitute for Vim 5.7 C/C++ syntax definition 
(<VIMDIR>/syntax/c.vim): doxy special comment block 
(/*! ... */, /** ... */, //! ... and //** ...) have a different color than normal comments, 
all tags (\xxx and @xxx) are recognized only if inserted in a special comment block
and someone (todo, note, warning) are highlighted
All lines modified/added to the standard c.vim are marked with a comment (DOXY).

Emilio Riva