[Lazarus] New Help System & Viewer - sneak preview

[Marco van de Voort]

On Thu, Oct 01, 2009 at 09:55:55PM +0200, Graeme Geldenhuys wrote:
> >  > Explain "module"?
> >
> > Bundles of help generated separately from eachother.
> 
> It's possible, and I have seen INF files that do that, but I don't
> know the tag format involved. I'll search the INF Reference manual for
> clues tomorrow.

I think that is an important concept because of e.g. the non-synchronous
nature of FPC and Lazarus.

> >  parts are not implemented yet. Fulltext search is fine and efficient, except
> >  for the generation (LCL takes 4 minutes to generate)
> 
> I'll report back tomorrow after I generated the IPF files. But I can't
> imagine the IPF Compiler taking that lock. I have thrown quite large
> help docs at it and they normally complete in seconds. I'll give exact
> figures tomorrow.
 
MS' help compiler is probably a lot faster too, this is the own lib.
 
> > CHM also allows to have a "toplevel" CHM that overrides the TOC and Index
> >  for the "slave" CHMs.
> 
> Does that mean you have to compile a special "toplevel" CHM?

Yes.

> You can't simply concat them from the command line, at runtime? If CHM
> can't at runtime, then the "toplevel" idea is pretty useless.

You can merge the indexes and concat the TOCs at load time. For maximum
speed you can even cache the result (keep in mind that CHM collections of
Borland and MS go into the tens or even up to 100MB)

But that is not the same as a master CHM where you can e.g. rearrange the
contents.

> When you buy products that come with CHM help, you don't have the source
> of the CHM.

Afaik not much info gets lost, so you can simple decompile. At least when
CHM lib will support all features (though it is not that far off)

> Also every time you want to add a new CHM to the "toplevel", you have to
> edit and recompile the toplevel CHM. Definately not ideal.

Yes. But that is the burden of custom content. Still, the number of main
manuals of FPC/Lazarus doesn't change that often so a nice customized
toplevel CHM (one for FPC alone, one also for Lazarus) could be nice.

> > You already encountered that. There only is HTML of ref,user etc. (there
> >  might be others, but other converters might be an adventure. And after that
> >  with fixing HTML layout, I don't want to ever go there again)
> 
> The current ref and user docs are not in HTML, they are originally in
> LaTeX. And just as you have a LaTeX to HTML converted, so you can have
> a LaTeX to IPF converted.

I know it is latex. I also know it is particularly hard to convert, I was
merely being practical.

Since as far as analogies go, LaTeX to HTML still sucks after 10 years, and
I considered waiting 10 years for IPF a bit too much.
 
> >  > The INF has a very easy to learn mark-up language (48 tags to be
> >  > exact) - similar to HTML and XML tags so should be easy to learn.
> >
> > And nobody knows them. And no system outputs them.
> 
> They are pretty self explanitory. Not to mention, I will probably
> implement some preprocessor or GUI editor for it (like FPDOC Editors
> hiding the XML structure). This is a no-brainer to do.

As 50 competing wiki formats, non of which really work.
 
> > I'm thinking about changing the Text IDE to CHM only in time. But not
> > yet
> 
> I heard many objects about that. Of one, other platforms have all
> there class and api help in different (non CHM) formats, so they will
> not be able to integrate that with the IDE.

Sure, just convert.