[Lazarus] Network connections

[SteveG]

2009/12/29 Marco van de Voort <marcov at 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/