Re: Yelp document chunking



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
> 
> file:///path/to/file.xml?section357

Agreed.

> 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.

Regards,
  Mikael Hallendal

-- 
Mikael Hallendal              http://micke.hallendal.net/
Stockholm, Sweden             Cell: +46 (0)709 718 918




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]