custom layout does not always honor visibility attribute in the index (Origin: bugzilla #634116)

[doxygen]

status NEW severity normal in component general for ---
Reported in version 1.7.2-SVN on platform Other
Assigned to: Dimitri van Heesch

On 2010-11-05 20:02:49 +0000, Daniel Franke wrote:

In an attempt to work around PR611413 [Ambiguous header: Modules (i.e.
Classes) vs. Modules (i.e. Groups)], I had a look at the LAYOUT_FILE.

As I understand it, this should provide the means to relabel some headings,
in particular the modules/namespaces ones.

I generated a layout file with `doxygen -l` and modified it to:

  <tab type="modules" visible="yes" title="Groups"/>

After rebuilding the documentation, 
 (a) the main page has the "Groups" label in the TOC
 (b) the INDEX has the "Groups" label
 (c) when clicking the link to modules.html, the caption is "Modules", not
"Groups"
 (d) likewise in the QHC output, the tree item has the caption "Modules"

Same holds for namespaces and possibly for other sections.

On 2010-12-20 14:07:27 +0000, Jake Colman wrote:

The TreeView panel has the same issue in that it displays "Modules" instead
of "Groups".

On 2010-12-20 21:06:42 +0000, Dimitri van Heesch wrote:

Confirmed. Should be fixed in the next subversion update.

On 2010-12-25 18:05:26 +0000, Daniel Franke wrote:

(In reply to comment # 2)
> Confirmed. Should be fixed in the next subversion update.

Not fully.
I do get the proper heading now, so that's already an improvement. However,
the modules page now reads:
-- 8< --
Groups

Here is a list of all modules:
[...]
-- 8< --
Here, "Groups" is the changed title. Is it possible to omit the intro? Or
have it parametrized?



Second, the visibility of at least these elements is not taken into account:
  <navindex>
    <tab type="namespaces" visible="yes" title="">
      <tab type="namespaces" visible="yes" title="MODULEs"/>
      <tab type="namespacemembers" visible="no" title=""/>
    </tab>
    <tab type="classes" visible="yes" title="">
      <tab type="classes" visible="yes" title="Derived TYPEs"/>
      <tab type="classindex" visible="no" title=""/>                 
      <tab type="classmembers" visible="no" title=""/>
    </tab>

Even with visible="no", they are still listed and if the title is changed,
the modified title is shown (tested with QCH output only).

On 2011-01-03 19:01:33 +0000, Dimitri van Heesch wrote:

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.7.3. Please verify if this is indeed the case. Reopen the
bug if you think it is not fixed and please include any additional
information
that you think can be relevant.

On 2011-01-09 00:42:14 +0000, Daniel Franke wrote:

Reopen. In r753, comment # 3 still applies.

On 2011-01-09 08:43:33 +0000, Dimitri van Heesch wrote:

In 1.7.3 I've added the "intro" attribute to the relevant tab tags. This can
be used to customize the introduction texts.

Can you check if this solves your problem?

On 2011-01-09 12:20:28 +0000, Daniel Franke wrote:

(In reply to comment # 6)
> In 1.7.3 I've added the "intro" attribute to the relevant tab tags. This
can be
> used to customize the introduction texts.
> 
> Can you check if this solves your problem?

Regenerated the layout file, got the intro-tags. Assuming that they expect
yes|no parameters, I set them accordingly, but can't observe any difference.
For this:

    <tab type="namespaces" visible="yes" title="">
      <tab type="namespaces" visible="yes" title="xxxModules" intro="yes"/>
      <tab type="namespacemembers" visible="no" title="xxxModuleMembersxxx"
intro="no"/>
    </tab>

I still see both entries in the menu on the left, named "xxxModules" and
"xxxModuleMembersxxx" respectively. However, the latter should not be there.

On 2011-01-09 12:32:28 +0000, Dimitri van Heesch wrote:

Hi Daniel,

The "intro" attribute can be used to specify the text used as an
introduction on the page, i.e. the "Here is a list of all modules" line.
Empty means the default text, so it is NOT a yes/no parameter, but an
alternative text.

I overlooked the second part of your observation; that visibility="no" does
not work, which is indeed still a problem.

On 2011-01-09 17:11:10 +0000, Daniel Franke wrote:

(In reply to comment # 8)
> The "intro" attribute can be used to specify the text used as an
introduction
> on the page, i.e. the "Here is a list of all modules" line. 
> Empty means the default text, so it is NOT a yes/no parameter, but an
> alternative text.

Ah, yes, that makes sense. I wondered. Yes, that works - thanks! :)

[sambo22]

visible="no" does not work in Doxygen 1.9.6. Resorted to commenting out elements.

[albert-github]

@sambo22 just

visible="no" does not work in Doxygen 1.9.6

is not much to work with,

• Can you please attach a, small, self contained example (source+configuration file in a, compressed, tar or zip file) that allows us to reproduce the problem? Please don't add external links as they might not be persistent.

especially of interest is which visible="no" does not work.

[sambo22]

Well, it did work for group::briefdescription, but trying to hide group::memberdecl::defines does not hide the macros.
Line 190 ->

[albert-github]

From the images it is very hard to reproduce the problem from just an image and as there is only some output there is no case to check against, so please:

• attach a, small, self contained example (source+configuration file in a, compressed, tar or zip file) that allows us to reproduce the problem? Please don't add external links as they might not be persistent.

When I interpret the images correctly you have problems with the fact that with defines in the groups part the visible="no" doesn't work (and probably you had also problems with the enums?). It is likely that the problem also occurs with the other elements.

There is a proposed pull request for this issue: #9290

[albert-github]

Code has been integrated in master on GitHub (please don't close the issue as this will be done at the moment of an official release).

[doxygen]

This issue was previously marked 'fixed but not released',
which means it should be fixed in doxygen version 1.9.7.
Please verify if this is indeed the case. Reopen the
issue if you think it is not fixed and please include any additional information
that you think can be relevant (preferably in the form of a self-contained example).