"Reece Dunn" <[EMAIL PROTECTED]> writes:

> Vladimir Prus wrote:
>>David Abrahams wrote:
>> > There's way too much detail in the TOC at the beginning of the
>> > generated BoostBook docs, which makes it almost impossible to
>> > navigate and very imposing to a newcomer.  Can that be fixed?
>>
>>Well, Boost.Build docs use:
>>
>>   boostbook userman : src/userman.xml
>>       : <xsl:param>toc.section.depth=1
>>          ........
>>
>>to mitigate this issue a bit. I'm not sure if this can/should be improved
>>further -- that's a question to Boost.Book experts.
>
> If you let me know what kind of structure/design you are looking for,
> I'll see if I can implement it. However it may be a week or so before
> I can give you anything. It may also require overriding the DocBook
> code which is something you want to keep to a minimum.

Well it seems to me that the TOC on the front page should list only
the individual libraries and show no detail of their documentation
structure.

> Also, the lack of script support means that you can't implement a
> collapsable heirarchy :(.

Actually I don't think scripting is completely out-of-the-question.
See http://article.gmane.org/gmane.comp.lib.boost.devel/90591 for
example.  I think the main reason we decided to ban scripting in Boost
web pages was that the chance of coming up with 20 different
nonportable and variously-annoying applications of it is too high.  If
we could manage a single instance of the script code and if there was
an alternative for browsers that don't support scripting, I think that
would probably be OK.  It might be worth trying for one release, to
see how it goes over.  It would also eliminate at least one excuse
that certain library maintainers use for not improving their
documentation ;->

> One possibility may be to support frames with the Boost banner in a
> top pane, the top-level ToC contents in a left pane that links to an
> expanded ToC for that chapter in the main pane. The navigation (prev,
> next) will be in the content in the main pane at the top/bottom of the
> document as is in the existing split HTML generation. The main content
> will also have a home link that directs the browser window to the
> frame content (<a target = "_top" href = "frames.html">home</a>).
>
> Are frames allowed in Boost documents? Thoughts? Alternate ideas?

Sure, frames are allowed, as are CSSes, which are more powerful than
most people know.

I think you *can* implement a collapsible hierarchy with frames, just
by automatically generating the right index pages.  I don't think it's
really helpful to have collapsibility at every level of hierarchy
anyway.  Those interfaces where everything collapses tend to be one of
those "script annoyances" I was talking about earlier ;-)


-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Boost-docs mailing list
[EMAIL PROTECTED]
Unsubscribe and other administrative requests: 
https://lists.sourceforge.net/lists/listinfo/boost-docs

Reply via email to