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