[fpc-pascal] helpsystem, some numbers

Marco van de Voort marcov at stack.nl
Tue Oct 28 17:06:06 CET 2008


In our previous episode, Graeme Geldenhuys said:
> And for Linux (Gnome and KDE) you are relying on 3rd party packages
> that as far as I have found doesn't come standard with any Linux
> distro I tried.

Fedora had both in YUM iirc, though kchmviewer was flaky. But I'm not
relying on them, they are additional.

> Plus the Gnome and KDE ones differ in performance and
> features.

While implementing the native Lazarus viewer, it could be easily seen, if
you naievely loaded the topics/index into the treeviews, the lazarus version
was as slow as gnome/kde. The textmode IDE was a lot faster.

Ergo: the problem is a simplistic treeview widget approach, not the CHM
itself. Vincent was already looking into it what could be done to speed it
up.

> Also the whole point of fpGUI is to give the end-user a consistent UI even
> if they switch between Linux and Windows. Our franchisees are such a case
> in point. They have centres that have mixed OS's next to each other.
> Learners come for lessons and grab the first available PC. One day they
> can be on Linux the next on Windows.

Well, I lean towards using native windows help for chm. But that can of
course be the same lazarus viewer too, there is no reason why it would be
needed. One could even give the user the choice.
 
> > Moreover you can get heaps of authoring tools for it, and the fpdoc process
> > is validated for it. And FPC comes with native encoders and decoders units
> 
> True, that is one benefit of CHM. Though fpdoc already creates a nice
> structure and some index files. So it should be much trouble working
> with what fpdoc already does with HTML output. TOC and improved
> Indexing can always be added to fpdoc in required.

It's already in there.
 
> > Probably with any own invention is that you are your own island again.
> > Usually I'm the one argueing that, but a few percent compression is not
> > worth the trouble for me.
> 
> Well considering that the RTL CHM size example has been reduced by
> more than half with 7-zip, that's a nice push for supporting
> alternative compression.

Not really, the 7zip value is not final. First, test with
something that 100% sure can extract single files, and a pascal version.
Then we'll compare again.

Moreover, I'm not that interest in one mb.

> We ship updates of our product on a single CD every six months (500+
> centres). We are already pressed for space, so every little bit helps.
> Plus having to ship 2 CD's to every centre will hugely impact on printing
> and postage costs.

That's possible, but maybe there are ways to save space that don't hurt the
customer with a insular help system.

> > If you have more data about what they have working that would be nice.
> 
> tiOPF has abstract classes for Compression and Encryption in the
> 'Core' directory.
> Actual implementations are in the 'Options' directory.

Ah, I thought they had a helpsystem. Nevermind.



More information about the fpc-pascal mailing list