Vladimir Prus-3 wrote
Yes. I think any solution with frames will have the same problem. You can possibly redo it without frames, using divs instead, but then you'd have to remember the tree state between different pages. Or, you can do an actual webapp :-/
As I said, I'm aware of the situation, I just never considered it a big enough issue to justify giving up the navigator - which I personally find very convenient. I believe it would be possible to create an xslt transform which would take all or any of the output produced by BoostBook/DocBook and generate a "Boost document navigator" which would be in a separate, floating window so that the selected documentation page would display it's own url. This would features. a) Be very convenient to use to navigate boost documentation - at least the BoostBook/DocBook ones. b) Be "free" in that it wouldn't require any re-work of any documentation already in BoostBook/DocBook (and of course QuickBook) by library authors. c) Work on both local copies of the documentation as weil as the remote versions at boost.org. c) Require creation of the XSLT transform. According to the hype this is easy. In practice it's a PITA. Maybe we could convince some GSOC candidate to take on this relatively small self contained project. The funny thing there is that the creation and positive reception of of such a facility would would answer your original question in the affirmative - which I guess isn't what you originally had in mind. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Do-we-need-BoostBook-tp4669821p4669917.ht... Sent from the Boost - Dev mailing list archive at Nabble.com.