Re: Yelp document chunking
- From: Mikael Hallendal <micke imendo com>
- To: Shaun McCance <shaunm wolfram com>
- Cc: John Fleck <jfleck inkstain net>, GNOME Documentation list <gnome-doc-list gnome org>
- Subject: Re: Yelp document chunking
- Date: 21 May 2003 00:26:59 +0200
tis 2003-05-20 klockan 22.25 skrev Shaun McCance:
> Upon thinking about it, I've decided that I really like this "flat"
> approach. The sidebar would then be a simple list, rather than a
> tree. This would also make it easier to present the sidebar
> differently, which could be useful for any UI redesign that comes
> about for bug #91610. On a related note, I would like the toc and
> front matter to be listed in the sidebar.
The sidebar doesn't have to reflect the chunking though. I mean, you
can have both sect1 and sect2 in the sidebar and clicking a sect2 it
opens the sect1-chunk and scrolls to sect2, right?
> App developers shouldn't have to worry about how we're chunking.
> They should be able to have the Help button point to
> Then Yelp should be able to figure out that 'section3' is the relevant
> chunk, and that 'section357' is a place to scroll to in that chunk. If
> we can implement the former (which really, really ought to work), then
> the latter can be accomplished by setting up a link translation table.
Currently the entire HTML document is stored in memory in Yelp and when
you need a certain chunk you retrieve it from the document. This way I
don't think we need a translation table.
Just search for the Section section357 in the document, when found
search backwards until you find a chunk-delimeter and then show the
entire chunk and reposition to section357.
> How easy this is to implement depends on how well gtkhtml supports it.
> I don't really know gtkhtml very well, so it would take me a little
> while even to know if I can implement this.
Gtkhtml2 supports scrolling to a certain anchor if that's what you mean.
Mikael Hallendal http://micke.hallendal.net/
Stockholm, Sweden Cell: +46 (0)709 718 918
] [Thread Prev