discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] a call for a better wiki


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] a call for a better wiki
Date: Sun, 23 Mar 2008 21:41:03 -0700
User-agent: Mutt/1.5.17 (2007-11-01)

On Mon, Mar 24, 2008 at 12:25:43AM -0400, Josh Blum wrote:
> Nifty!
>
> Doxygen always surprises me. I have been building a category tree myself 
> for the blocks in grc: 
> http://gnuradio.org/trac/browser/grc/branches/grc_reloaded/src/grc_gnuradio/data/block_tree.xml
>
> I will take a few tips from the doxygen groups (since they are a bit more 
> comprehensive). The main difference with the grc list is that the list 
> contains only signal blocks, and only signal blocks that can be used in 
> grc. Also some custom blocks.
>
> Some quirks with using the current doxygen groups:
> 1) The python based blocks (blks2 and wxgui) seem to be missing.
> 2) Signal blocks and helper functions (gri stuff) are mixed into the same 
> group. Not that this is bad, but its not the same as having just a list of 
> signal blocks.

I agree this is probably wrong.

I think there ought to be a top-level category for gr_blocks, that
contains all the other block subcategories under it.  The gri_ and
gr_fir_* stuff should not be under the block category.

> 3) Some blocks are really specific and only used as a part of a bigger 
> signal block.

> To start, we could make a wiki page that listed each major group and liked 
> to the doxygen group page. But a comprehensive list of just signal blocks, 
> that someone would actually use, maybe this would have to be manually 
> compiled.
>
> Thoughts?

Let's come to some kind of agreement on the category list, then edit
the headers of any miscategorized classes, then create the wiki page
linking to the updated docs.

The python stuff currently gets included in a kind of screwy
way.  Somebody should take a look at it and sort it out.  We may want
to consider generating the xml output, then filtering it to rename/fix
the python extracted docs so that they fit more naturally into the
hierarchy.   I think you can feed the modified xml back into doxygen and
have it generate the html from that.  It's also likely that the docs
embedded in the python will need some work.  Some of them have the
class and constructor docs conflated.

Eric




reply via email to

[Prev in Thread] Current Thread [Next in Thread]