I must have been looking in all the wrong places

[venta]

Does anyone know much about doxygen?

I am generating a whole bunch of html files from some C++ headers. The per-function documentation pages I get out all have the following element:

<div class="navtab">
....
</div>

which forms a sort of sidebar-style index to all the other functions whose docs were generated from the header.

I don't want this to be present. I thought that GENERATE_TREEVIEW=NO in the config file would suppress it, but it doesn't. (At least, it doesn't using doxygen 1.5.4 or 1.7.4, and I can't find any references online to it being broken. So maybe that isn't what that switch is meant to do, though it sounds like it in the docs.)

DISABLE_INDEX=YES also isn't the right answer - that disables a different bit of auto-generated guff which I also don't want.

Does anyone:
(a) know what GENERATE_TREEVIEW actually governs?
(b) know what switch I need to set to suppress this sidebar-index thing?
(c) as a last resort, have any ideas of how to painlessly remove a div element and all its contents from an html document? (I have no experience of Perl or anything like that, though I suspect I may be about to acquire some if (b) cannot be solved.)

Auxiliary comment: no, I can't just hide the div element using CSS. Well, I can, obviously. But it's not good enough. I actually need that element removed from the html.

Comments

[mister-jack.livejournal.com]

I've not done a lot with Doxygen, but I would have expected it to too.

What happens if you have USE_INLINE_TREES=YES and GENERATE_TREEVIEW=NO ? Have you got that?

(Oh, and for (b), a painful regex would suffice).

[venta.livejournal.com]

My doxygen.cfg doesn't seem to have a value set for USE_INLINE_TREES, but adding one (YES) doesn't seem to make any difference.

(Oh, and for (b), a painful regex would suffice).

... I'm not sure I'm capable of producing a regexp that painful!

I could just about get away with just removing the innermost div element, so wouldn't have to deal with nested elements much, but my regexping skills are possibly still not up to the job. Always time to learn, I suppose :)

[mister-jack.livejournal.com]

I meant to suggest USE_INLINE_TREES=NO might fix it if you had USE_INLINE_TREES=YES...

Are the < div >s aligned to the left or is there indenting? Are the contents of the div indented? If not are there nested divs inside it?

[venta.livejournal.com]

I meant to suggest USE_INLINE_TREES=NO might fix it

I did wonder, so I tried that one as well. Neither seemed to make any difference to the HTML output.

The tags are all indented (using spaces, not tabs). The relevant div has nothing but a table (and of course things you'd expect to find in tables) inside it.

[mister-jack.livejournal.com]

I think the regex you will need then is \r?\n <div class="navtab">(.*?)\r?\n </div>

Where the spaces between the \n and and < are the same as whatever indentation it is. If you don't want to worry about the possibility of nested div tags you could just use <div class="navtab">(.*?)</div> and then just stick that into your favourite regex capable text editor and do a replace in files.

[venta.livejournal.com]

I think the regex you will need then is...

Thanks. I'll have a look at that if I don't get any sense from the doxygen forum I also sent the question to earlier today - if not generating the div in the first place is an option, I'd sooner go with that.

do a replace in files

This will have to be done every time the files are autogenerated, from a makefile. So it needs to be a bit less human-assisted than that :) Once I've comprehended that actual regexp, then hopefully I can communicate it to sed and do it that way.

[mister-jack.livejournal.com]

I'd check it works manually first ;)

[venta.livejournal.com]

Nah, what can possibly go wrong...

(That came under the 'comprehending' part ;)

Cheers.

[venta.livejournal.com]

hopefully I can communicate it to sed

This will be a waste of time, Elizabeth. Sed is purely line-based and won't match over linebreaks.

[bateleur.livejournal.com]

Personally I take the view that millions of programmer hours worldwide could be saved if sed was removed from every system by default. That way nobody could every think "I have sed and not perl on this system, so I'll try doing it with sed".

[venta.livejournal.com]

My argument is "I know how to use sed[*] I don't know how to use perl, so I'll try doing it with sed". However, if your plan had been implemented I probably wouldn't be in that situation!

[*] For certain limited values of "know" and "use".

[ewx.livejournal.com]

That div.navtab is an inalienable part of SEPARATE_MEMBER_PAGES = YES. If you want per-member pages and don't want the navtab then you're going to have to modify either the output or Doxygen. The latter should be a fairly easy modification to MemberList::writeDocumentationPage().

[venta.livejournal.com]

Ah. Right. Thank you, that's useful information.

[ewx.livejournal.com]

Is modifying Doxygen a reasonable option? (It was for us, but that might not be true everywhere…)

[venta.livejournal.com]

I'm not actually sure yet. Given that it would necessitate patching doxygen every time we update the versions on our build machines I don't think it's an option I'm hugely excited about, but I figured I should look at it.

I suspect some Perl to modify the output is probably going to be the route of choice.

But on Monday :)

[ewx.livejournal.com]

The way we did it was to import doxygen (and patches) into our build system, and have the components that needed HTML docs invoke that version rather than look in /usr/bin.

[ewx.livejournal.com]

GENERATE_TREEVIEW creates a frame in which a hierarchical map of the documentation can be found. It should be pretty hard to miss if you turn it on.

[venta.livejournal.com]

Hmm, no. It was on in the first place, which is why it seemed likely to me that turning it off would make the relevant bit go away. Turning it off seems to make no appreciable difference.

Which is probably something to do with frames support :( I'm definitely dealing with things beyond my ken, here...

[ewx.livejournal.com]

Left hand side of this.

[thefon.livejournal.com]

At what point does the div need to be removed? Can you just remove it with javascript?

[venta.livejournal.com]

I have a makefile which generates some docs from doxygen comments (and also generates some more docs from a bunch of DocBook XML, and so on).

Shortly afterwards, it builds all those docs into a .chm file using the utterly nasty M$ HTMLHelp, and also into a zip in the format Eclipse understands.

Somewhere between those two stages, I need to remove it. I have no idea if you can call Javascript from a makefile, but it doesn't sound like the natural route to go down to me :)

[beckyl.livejournal.com]

now, y'see, I was looking at 'doxygen' and assuming some kind of di-oxide scientific thingy, which, knowing your journal posts, there would then have been a link to an article where someone had created a prototype of some new fantastic clean superfuel with slightly dodgy 'scientific' claims you wanted to check your understanding of. Not the gibberish under the cut. So yeah, disappointed in you!