2009/12/29 Marco van de Voort <mar...@stack.nl>: >> Unlike Windows, there is no default CHM viewer for Linux. > > True. The default depends on desktop suite (gnome ->gnorpm, KDE -> > kchmviewer, rest mostly xchm or use a CHM plugin in mozilla)
Not even. I use ChmSee which is also GTK based, but is a lot faster than GnoCHM. :-) >> So if lhelp is a CHM viewer, why can't we use it for other CHM (non >> Lazarus related) files. > > What is the point? There are already at least 4. Admitted, none is default, > but a 5th one won't suddenly become default either. OK, I see my previous email was misunderstood or I misunderstood what I was replying too. There was mention that lhelp will search for CHM files. This is what confused me. I thought lhelp has some hard coded seach text that always searches for RTL, FCL and LCL and Lazarus package help. This is where I got confused between the usage of lhelp compared to other CHM viewers. But apparently I misunderstood the "search for CHM files" text. I believe there is no "hard coded search for know CHM files" in the lhelp code. > So what? Then at least we can focus lhelp sharply on Lazarus' needs, and not > get bogged down in Wine users complaints and feature wishes, just to save At the moment lhelp seems just like any of the other CHM viewers available under Linux? (to me that is) What exactly makes lhelp different other than maybe performance? Also is there a differences between RTL, FCL and LCL's .CHM files compared to other CHM files shipped with Windows software? If not, then what is the "specific lazarus needs" you are referring too - command line parameter support to enable automatic searches etc? > The other viewers are just that, viewers/ebook readers. > lhelp is meant as the backend of an integrated helpsystem. For an IDE. So what is LCL based applications supposed to use for application help if lhelp is specific for the IDE only? I thought the goal of lhelp is the be a help viewer that can be used by the IDE and applications built with the IDE. > So we keep our own, and keep the documentation in a way that multiple > formats can be generated (which I admit is not the case for the latex docs), > and wait till there is really a suitable alternative. I have to agree with this. Latex is excellent for printed documentation, but is not suitable for a "multiple format" output system. LaTeX to HTML or LaTeX to CHM just looks crap! That is why I decided to take the long route and manually convert ref.tex (ref.pdf) to INF format - taking advantage of the features and layout that INF supports. I also wrote a complete new INF backend writer for fpdoc to generate *much better* looking INF documentation of RTL, FCL and LCL. The manual conversion of FPC Language Reference document is actually going quite quickly - LaTeX and INF have a lot in common (describing the content, not the layout). I'm near completion with the ref doc conversion and the way I did it, w make that it is easy to keep it in sync with the Latex version. > First, lhelp is not a viewer but a helpsystem backend. It would be called > "lview" otherwise ;-) Please explain what makes lhelp different? At the moment it simply (clearly to the untrained eye) looks just like a ordinary chm viewer. Only obvious difference is that it's cross platform enabled thanks to FPC and LCL. -- Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus