[Lazarus] Define for the used windgetset

[Joost van der Sluis]

On Tue, Dec 29, 2009 at 03:44:33PM +0200, Graeme Geldenhuys wrote:
> Not even. I use ChmSee which is also GTK based, but is a lot faster
> than GnoCHM.  :-)

I use kchmviewer mostly to doublecheck, and simply XP/Vista's CHM support.
I had some problems with gnochm in the past, and the browser plugin was
useless with larger files. 

But I'm mostly testing for features etc, so speed is not an objective (for
that i use lhelp, or more often, fp)

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

Lazarus has a chm registry. Currently rtl, fcl,lcl are hardcoded in the UI
that registers those in the registry, but afaik that is a GUI, not system
limitation.

lhelp doesn't search at all, it gets its data from lazarus, and is fully
instrumentable.

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

The main one that it is instrumentable in a two way direction. IOW they are
linked over IPC means, and afaik that is a two way connection. So lhelp can
also generate events that Lazarus could react too (e.g. jump to function
definition from help, disambiguation choices, copy and paste etc)

The more minor reasons are footprint, dependancies and being integral part
of the project. (iow control of both sides)

> Also is there a differences between RTL, FCL and LCL's .CHM files compared
> to other CHM files shipped with Windows software? 

No other than that they are not generated by the MS help compiler. 

This minor difference works two ways, the con is that the FPC chm compilers
might have bugs and/or missing features (which we are stamping out bit by
bit), and the pro is the fact that the MS helpcompiler is notoriously bugged
(specially with larger helpfiles), which makes some functionality hard to
access. Having it as a library is also great for Lazarus' documentation
systems.

I don't have an example yet, but when researching CHM, you constantly find
references about both the help control and help compiler limitations.

> If not, then what is the "specific lazarus needs" you are referring too -
> command line parameter support to enable automatic searches etc?

Lhelp is a server, and Lazarus is a client (and potentially the applications
it generates are a second). You can create any interaction one could need.
Multiple popup screens, test views of documentation parts, running results
of a CHM search through data of codetools to see if irrelevant options can
be eliminated, the sky is the limit.

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

That's the point I originally thought you meant. I wish I had a smart
answer. The objective is of course both, but its current needs are mostly
geared towards the IDE. IOW it will need fleshing out, and exploration.

I don't work on lazarus<-> lhelp much, but I do like the general setup,
except maybe the fact that lazarus has a plugin system that forces load of
all indexes on start.  That's a time and memory hog. 

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

I've had this discussion now (for 4 or 5 different latex2 converters) more
times than I would have liked. All these failed before. Including postedit
events etc. Same with the original ps2pdf conversions (before pdflatex),
which were very nicely postedited, but a while later that initiative also
failed (but in that case we got saved by improvements in pdflatex and
hyperref)

Maybe it is because the converters are general latex2* converters, and a
specific one under our control would be more succesful, without the kind of
infinite catch up that you describe (which usually works fine for a few
versions till the maintainer runs out of steam).

But that first would mean agreeing on a latex subset, something that Michael
always has refused afaik.

Switching to another format is no solution IMHO, specially not as arcane as
INF. 

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

See above.