Jonathan Turkanis wrote:
If we do this, then it should be possible to do something like:
<span onclick = "follow_link(1.5)">Chapter 1.5</span>
This would be embedded in an anchor element, to allow links to work on no-script browsers? I think this should work.
I'll see if I can get frames/tree_control working in Boost.Book and start experimenting with the code.
With regards to the page refreshing, this happens when you select "sync" anyway.
Yes, but I was thinking that "sync" would be used relatively infrequently, whereas following links within a page is common.
Sure.
Is it possible to use '#' instead of '?', so the browsers won't refresh the docs.
If we use Rene's idea of displaying the tree in the content frame, then yes (I think). Otherwise, the url with the correct fragement identifier won't be displayed in the address bar.
Okay.
Including the tree in the content frame is a big problem, though. When I replied to Rene I was mostly worried about download times when viewing the docs online. But if a large part of the docs eventually use trees, it could unnecessarily increase the size of the Boost distribution. We could use iframes, but this won't work for old browsers.
Sure. It would be a good idea to have a working XSLT for Boost.Book/tree_control first so we can try out the various ideas.
I'd like to focus on:
1. Providing a tree control which library authors can add to hand-written docs 2. Allowing docs generated with Boost.Book to have a built-in tree control, with automatic synchronization if possible
1) is basically done, unless someone has an idea how to eliminate the need for [sync] 2) is doable, with hitch that linking within a page causes a reload (unless I misunderstood your suggestion)
The main steps for writing the Boost.Book XSLT code are: 1. Disabling section ToC's; 2. Overriding the default ToC mechanism in favour of the tree control menu; 3. Providing "chunks" for the main frame page and the ToC page; 4. Iterating over the various sections and extracting the names of the "chunks" to use as the links; 5. Modifying the way sections are generated if necessary to accommodate the new control; 6. Anything I've forgotten.
I think only time will tell whether it's more annoying to have to manually [sync] the documentation or to reload the docs when linking within a page. So I'd say two variants of 2) should be pursued: one which produces docs using the existing tree component, and one which produces auto-syncing docs.
Once the code is written it should be possible to play around with what it generates to test the ideas that you and Rene are suggesting. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/