Re: Bug #115289

[Shaun McCance <shaunm wolfram com>]

On Wed, 2003-08-20 at 15:06, Luis Villa wrote:
> On Wed, 2003-08-20 at 08:47, Mikael Hallendal wrote:
> > ons 2003-08-20 klockan 11.05 skrev Murray Cumming:
> > > On Wed, 2003-08-20 at 10:45, Shaun McCance wrote:
> > > > Also, and it's a slight UI change.  The title page and toc are placed in
> > > > the sidebar for a document along with the other chunks. 
> > > 
> > > Ideally, the speed-up patch would be separate from the UI-change patch.
> > > I don't see how the UI-change is necessary for the speed-up.
> > 
> > Hmm, it's not really a UI change. The only difference is that "About
> > This Document" and "Contents" becomes part of the contents tree. Just as
> > if a document would add them there, which I doubt anyone would consider
> > a UI change.
> 
> Up to the docs people, then, I guess- will this impact any screenshots?

No.  Let me clarify what this "UI change" is.  Yelp creates chunks, or
pages, for each section in a document.  When you're viewing a document,
the sidebar gives you a listing of all the chunks.  Click a row in the
sidebar and the corresponding chunk appears.  In addition to creating a
chunk for each section, Yelp also creates a chunk for a title page, and
a chunk for a table of contents.  However, currently the title page and
table of contents aren't listed in the sidebar.

This patch adds them to the sidebar.  From an interface standpoint, all
it does is add two more rows into a GtkTreeView.  This is the correct
thing to do anyway, as it provides a one-to-one correspondance between
chunks and sidebar entries.

Aside from it being correct, it's basically necessary to provide this
speed-up.  The whole idea of the speed-up is that the navigation links
at the top and bottom of each chunk are created in C by referencing the
same data structure used for the sidebar.  This way we avoid recomputing
something which is relatively expensive to compute in XSLT.  It could
technically be done without adding the entries in the sidebar, but it
would take far more code.  This is the cleanest, simplest, and most
correct implementation.

--
Shaun