On 6 September 2010 10:52, Marco van de Voort <mar...@stack.nl> wrote: > > When the recent discussion about git moved to fpc-other, that reminded me > that the last to-fpc-other discussion had loose ends :-)
Oh boy, this sounds serious. Doesn't not replying, also answer a
question. ;-) Just kidding.
> - Don't compare compressed sizes if you must depack to use. OR at least
> clearly annotate such (or provide both statistics)
Not 100% sure what you mean here. I thought I compared a INF file to a
CHM file to the unpacked HTML help archive. 3 size comparisons. Lets
use LCL.
lcl.inf -> 3.8MB
lcl.chm -> 10.9MB
but apparently you need the lcl.xct file too for keyword support
which is already
included in the INF file, so lets add that file too.
lcl.chm + lcl.xct -> 12.1MB
lcl help in HTML format -> 65MB (
This is the <lazarus>/docs/lcl/html/ directory after generating
the LCL help in
HTML format.
So as you can see, having the same content, but in different formats,
there is a big difference in size. So why download a larger archive,
when a smaller archive contains the same help content, plus index,
keyword search plus TOC etc...
At one stage (a couple months back), did a speed comparison between
the help viewers for use with Lazarus IDE as well. I used EpikTimer,
to wrap the code that loads a topic and displays that topic - ready
for a end-user to start reading the content. I compared DocView
against LHelp. In my tests, DocView was about 20+ times (on avg.)
faster than LHelp, loading and displaying the same topics.
I then disregarding the "displaying of topics", and only timed the
loading of topics. Again, DocView was considerably faster that LHelp.
I also did a speed comparison in loading of the help file itself, and
simply populating the Table of Content and Index. Again DocView was
some 20-25 times faster than LHelp. This I believe was after some
binary tree addition to the CHM code which should have increased the
CHM speed.
Another test I did was scrolling of loaded content. Load a large
topic, then drag the scrollbar button from the top to the bottom.
After all, help is there to me read, and the end-user is bound to
scroll the help. So my thinking was to test what the end-user would
experience. If memory serves me well, I used the LCL TApplication
topic (in INF help, that would be the TApplication Method Overview
node). LHelp was simply unusable, but apparently the HTML Viewer
component used by LHelp is to blame for that. Never the less, that is
the experience the end-user would get.
So if any of these tests and comparisons seem unfair in any way,
please let me know, and suggest any alternative way I can do similar
comparisons. My main point I was trying to get at was download size
(myself and many others I have limited internet bandwidth per month),
and end-user experience.
> The main reason seems to be to make html usable without an index tab left to
> it. This is useful for online use (though strictly, you could have an index
Just like the HTML or CHM help needs additional information to have
some form of navigation like a Table of Content, so do does the INF
format have additional information for TOC and Index support. A TOC
does not appear magically in INF, the fpdoc IPF writer needs to add
information in the IPF output for that. The Index is a different
matter. You can have built-in Index information in the INF file, but
DocView has a special ability to build it's own Index or or even use a
combined Index (one from the INF file, and one it generates itself).
> Example: If I press F1 in the textmode IDE on TStringlist, I go to the
> tstringlist overview page, and from there can go to all stringlist topics.
>
> If I do the same with .inf, I end up on tstringlist, but can go nowhere, and
> have to look up tstringlist methods in the main index.
I can count on my one hand how many times I have used the textmode FP
IDE. I was under the impression that the textmode IDE is a dying
project. Either way, I fired it up at tried it for the first time with
the INF files I generated recently. Attached is a screenshot of how I
setup textmode FP IDE for INF. I included two more screenshots (in
separate emails) showing what I saw. I used separate emails because I
don't know the attachment size limit in fpc-other mailing list. Do you
know?
Pressing F1 while the cursor was on TStringList, the help windows
showed me an Index page. A rather large list. I took a guess and
started typing TStringList, and it automatically jumped to TStringList
in the Index. I pressed Enter and saw the TStringList overview page
(image in part 1 email). The overview pages is what I would have
expected to see if I searched any help for TStringList. So this is
good so far.
I then tried the Prev / Next links you mentioned. These are not part
of the INF topics content by the way, they are inserted by textmode
IDE help system. I selected next, and it showed me the TStringList
Method Overview. As I expected too. It seems the prev/next links are
walking through the TOC tree - built into the INF file.
Then tabbing to one of the methods (Add() in this case), and pressing
Enter, it indeed showed me a blank help window. This is clearly some
bug in textmode IDE, because even the prev/next links inserted by
textmode IDE is not there. I have tested the INF files I generated
using various software. I used the iview program (IBM's official
Windows INF Help Viewer), and with OS/2's VIEW (official IBM OS/2
viewer), and eComStation's NewView (open source replacement for IBM's
view) and official help viewer of eComStation. In all these tests,
navigating hyperlinks inside topics worked fine. I quickly tested
rtl.inf and the TStringList.Add link with iview, and it does display
the Add() method help topic correctly.
I can supply you with a download link for the IBM Windows INF viewer
(iview) I use, if you want.
> In short, this might become a problem for integrating INF into other 3rd
> party helpsystems (e.g. editors) too.
Like I said above, the blank help pages is a textmode IDE issue, not a
issue in the INF files itself. DocView doesn't use any of the INF
reading code from the textmode IDE.
> Are prev/next provided by the reader systems (or e.g. by special macros), or
> are they in the content? If the former, probably all in-content links don't
As I mentioned above, those prev/next links are inserted by the
textmode IDE. They are not part of the actual INF files viewed. So
indeed, there is something strange (read bug) with the textmode IDE
code.
Seeing that I know the INF file structure quite well, I could take a
look at the textmode IDE INF reading code, but this will not be a high
priority for me. So it will be time permitting only.
BTW:
Is anybody actually using the textmode IDE?
--
Regards,
- Graeme -
_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
<<attachment: fp_ide_inf_setup.png>>
_______________________________________________ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-other
