http://www.lazarus.freepascal.org/index.php?PHPSESSID=40f7fe67db8568a9cbb6088b050d5bf5&topic=7854.0

Osvaldo Filho wrote

http://www.lazarus.freepascal.org/index.php?PHPSESSID=40f7fe67db8568a9cbb6088b050d5bf5&topic=7854.0

Very nice,

I've tried the same using Takanori Ito's code. But coudn't get it to work. Compiling went fine, but it didn't run. But thereafter I had exactly the same problem on windows using Delphi, using the original code.

Good that you got it working, I'll certainly have a .

I already downloaded the code, and have already some patches so it compiles on Linux and 64-bit.

Michael.

Michael Van Canneyt wrote

I already downloaded the code, and have already some patches so it compiles on Linux and 64-bit.

I'm excited about the possibility of using gecko as the rendering engine of lhelp. This is great news.

Andrew

Andrew Haines wrote

I'm excited about the possibility of using gecko as the rendering engine of lhelp. This is great news.

For displaying HTML that would be great, but at what cost? How much bigger is LHelp going to get (executable size) if you add a complete Gecko engine into the executable. :-(

Or does it use an existing Gecko install on your system and simply display output inside your application? That would still mean you need to have something like Firefox install before you application will work. That wouldn't be much of a problem under Linux, but will be under OS X, Windows etc..

Regards,
- Graeme -

2009/11/6 Graeme Geldenhuys :

Hmm, do we really need the functionality of the whole gecko engine just to display help? Are current pascal html display components that bad that it can't be fixed?

Henry

Henry Vermaak wrote

Hmm, do we really need the functionality of the whole gecko engine just to display help? Are current pascal html display components that bad that it can't be fixed?

My point exactly.

Regards,
- Graeme -

2009/11/6 Graeme Geldenhuys :

Ah, apologies, I replied to the wrong person. Where is my mind today...

Henry

Henry Vermaak wrote

Ah, apologies, I replied to the wrong person. Where is my mind today...

Lets blame it on the fact that it's Friday. ;-)

Regards,
- Graeme -

AFAIK Gecko is not limited to rendering HTML.

DoDi

Exactly. Gecko can also do JavaScript. In fact, I was able to run an ExtPascal app in a TGeckoBrowser component. Think about the possibilities that opens up.

Gecko is the real deal and I'm quite impressed by what Takanori has done.

As an alternative to having the user install Firefox, you can also just have the user install/unzip one of these:

http://releases.mozilla.org/pub/mozilla.org/xulrunner/releases/1.9.1.4/runtimes/

The one issue, and it's a big one, is that Gecko won't work on OS X with Lazarus since it's still on Carbon. And the Cocoa widgetset is only a prototype at this point (TForm, TButton).

Thanks.

-Phil

Thanks

2009/11/6 Hess, Philip J :

...

From: Hans-Peter Diettrich [] Sent: Friday, November 06, 2009 10:48 AM To: ; Lazarus mailing list Subject: Re: [Lazarus] Gecko on lazarus

Hans-Peter Diettrich wrote

AFAIK Gecko is not limited to rendering HTML.

That's not what I said. I simply meant that even though the Gecko engine will be good at rendering HTML (one of it's functions), the size of LHelp will be considerably bigger and will have more dependencies (it needs Firefox or gecko runtime engine installed first).

Having such extra "fat" or dependencies might not be such a good idea for a help viewer.

Regards,
- Graeme -

Having such extra "fat" or dependencies might not be such a good idea

for a help viewer.

But still it is good idea to take full support HTML and JS, for example Right To Left not supported with embed HTML viewers mentioned on the forums.
TWebBrowser in Delphi has the same dependencies, but IE already included in the system Windows.

Thanks

Zaher Dirkey wrote

TWebBrowser in Delphi has the same dependencies, but IE already included in the system Windows.

And that being the BIG difference! No extra deployment libraries needed when using TWebBrowser. This will not be the case with a Gecko engine.

Regards,
- Graeme -

On linux ???
rsrsrsr

2009/11/11 Graeme Geldenhuys :

Osvaldo Filho wrote

On linux ???

Yes, even on Linux. For example, you can have a KDE based distro which includes Konqueror instead of Mozilla Firefox.

This also applies to other platforms like Windows, Mac OS X or FreeBSD etc... None of them guaranteed to have Firefox installed by default.

Regards,
- Graeme -

I guess, the gecko renderer is optional and both ways of rendering should be supported.

If the internal (pascal) renderer is good enough, nobody will use the external Gecko renderer. OTOH, some people want to trade speed and resources for a better rendering in some cases.

You can compare it (a bit) with the internal and external (gnu ld) linker in the windows compiler. Nobody uses the external linker on windows, except if you think there is a bug in the internal linker (or are using the external assembler for debugging purposes).

Vincent

Vincent Snijders wrote

If the internal (pascal) renderer is good enough, nobody will use the external Gecko renderer. OTOH, some people want to trade speed and resources for a better rendering in some cases.

My personal opinion is that help files should not be that complex in layout design to require something as complex as Gecko to render correctly. That would also mean that those CHM files will probably look different when viewed with Windows CHM help viewer as well (rendering differences between IE vs Gecko).

Help files is about getting information across, not about eye-candy. Maybe it's just me, but that's what I think. :)

Regards,
- Graeme -

Graeme Geldenhuys wrote

And that being the BIG difference! No extra deployment libraries needed when using TWebBrowser. This will not be the case with a Gecko engine.

Is that me we cannot use the Engine if Firefox already installed in the system?

Vincent Snijders wrote

If the internal (pascal) renderer is good enough, nobody will use the external Gecko renderer. OTOH, some people want to trade speed and resources for a better rendering in some cases.

I think the internal renderer should and could be perfect (read fast,without any serious layout problems) for the own generated docs, because they are simple and we control both sides.

Then there could be an override option to open topics external CHMs with a full browser.

You can compare it (a bit) with the internal and external (gnu ld) linker in the windows compiler. Nobody uses the external linker on windows, except if you think there is a bug in the internal linker (or are using the external assembler for debugging purposes).

Good analogy. Though I shouldn't need to install such a browser (or even configure it) if I don't want to use it. It should be totally optional.

Yes, that might be useful. A lot of bug reports come from people throwing any chm file against lhelp assuming it will open any chm file, not just the lazarus help files. For those people, an escape route to Gecko could be offered.

Same for ld, everything works fine without, it is an option.

Vincent

By rights, on OS X the help should probably open in the OS X Help Viewer, not in lhelp or a browser. I believe Help Viewer can display most HTML. A quick and dirty way to use it is:

{$IFDEF DARWIN}
Shell('Open -a "Help Viewer" "' + HelpFile + '"');
{$ENDIF}

Thinking ahead, what it you wanted to put some level of interactivity or animation in parts of the help? A full browser would help out there.

Thanks.

-Phil

Can OS X Help Viewer open chm files? Can it use its index and table of contents?

Vincent

No idea. Maybe the lhelp develop knows the answer.

Hasn't CHM been abandoned by Microsoft due to security concerns?

Thanks.

-Phil

You don't have to configure or link to LD.

And apparnatly nobody noticed we ship a 2005 LD

2009/11/11 Vincent Snijders :

To be fair to all those users (including me). There was no mention that LHelp is only meant for Lazarus and FPC documentation. Is is said to be a CHM help viewer, so we use it as such. Especially Linux users that might have Windows apps installed and running via WINE.

But a option in LHelp to switch rendering engines would be good for compatibility. Alternatively simply point them to the Firefox add-on which allows Firefox to read CHM files directly. All viewing problems solved - but then still lacks searching and Index support.

2009/11/11 Hess, Philip J :

No idea. Maybe the lhelp develop knows the answer.

I doubt the Mac help viewer can. After all, CHM is a Microsoft format.

Hasn't CHM been abandoned by Microsoft due to security concerns?

It has been replaced by Microsoft Help 2 - yet another format. But CHM is still popular and used often.

As for the security concerns - in that case Microsoft should drop Windows, Office, IE, etc... ;-)

2009/11/11 Marco van de Voort :

And apparnatly nobody noticed we ship a 2005 LD

I did - two days ago when I setup Lazarus and FPC in a VirtualBox session for Windows testing. I thought by binutils was very old - most files dated 2005. I then downloaded the latest FPC & Lazarus installation and to my surprise, most binutils files are still 2005. :)

It has only been replaced in Visual Studio and e.g. Delphi. The average app doesn't (and can't) use MSHELP2, since it needs the MS SDK to be installed.

Note that this is all afaik, if sb has more info, please share.

MSHTML3 is pegged for the next VS in 2010, but it seems it has postponed to later VS versions before when the release date came close, so don't take that to literally.

As for the security concerns - in that case Microsoft should drop Windows, Office, IE, etc... ;-)

If there is any truth in it (I haven't seen anything like that), it is probably the use of IE in the viewer, not the format itself.

If there is a format problem, it is that it is an archive, just like ZIP is. You can stuff anything in it, and if you can get the viewer to interpret it, you can instrument it.

A bit a strange view, since it is a helpviewer designed to integrate with lazarus. It was never explicitely billed as being universal. There is kchmviewer, gnorpm, xchm and whatever for that.

Note btw that it could also be used/retargeted to provide application help. And sb wanting very "rich" content or control over rendering (CSS etc) might want to use a full browser.

But I assume that is the exception rather than the rule, specially in the forseeable future.

But a option in LHelp to switch rendering engines would be good for compatibility. Alternatively simply point them to the Firefox add-on which allows Firefox to read CHM files directly. All viewing problems solved - but then still lacks searching and Index support.

And, even more importantly, being instrumented by the IDE.

The most important function of Lazarus help is simply providing choices when sb presses F1 in the source.

Marco van de Voort wrote

It has only been replaced in Visual Studio and e.g. Delphi. The average app doesn't (and can't) use MSHELP2, since it needs the MS SDK to be installed.

Visual Studio and Office as for as I know (but then I don't use Windows so don't quote me on this). Also, Microsoft loves to use VS and Office as a launch pad for new features and then later become standard in Windows. So I'm pretty sure MSHelp2 or 3 will be the next help format for Windows.

If there is a format problem, it is that it is an archive, just like ZIP is. You can stuff anything in it, and if you can get the viewer to interpret it, you can instrument it.

You did note the simley face, right? But yes I agree, CHM is just some glorified archive.

Anyway, what really annoys me is that now even Google's Gmail considers CHM an executable. (Maybe because of IE bugs and that JavaScript is allowed inside CHM content). You cannot attach a CHM in Gmail, just like you cannot attached a .EXE in Gmail. F**ken annoying!!! There are much better ways to curb viruses from spreading that limiting the user to what attachments they may or may not use in emails.

Regards,
- Graeme -

Just to add some wood to the fire. I've implemented locally a reader for MSHelp 2 files. It only can read the file format and extract files so far. It doesn't yet know how to read the internal files that contain the toc, index or any other feature of the format(and may never if I don't find a spec). :)

Regards,

Andrew

I wrote an HH2 helpfile decompiler some time ago. I can try to find the sources, if you're interested in it.

DoDi

Hans-Peter Diettrich wrote

I wrote an HH2 helpfile decompiler some time ago. I can try to find the sources, if you're interested in it.

Yes I would be interested in that, thanks.

Currently I can extract any file from the hh2 file. I just don't know the file format of the internal files for the toc etc. My motivation is to read lit files (ebooks) which use the same format as mshelp2 but would certainly be interested in seeing how to read the files specific to the toc, index, and search db of help files.

I have implemented everything documented on this page: http://www.russotto.net/chm/itolitlsformat.html

Regards,

Andrew

so what happens on other OS'? what is used, if anything, with TWebBrowser on them? mac, *nix, bsd, etc...

waldo kitty wrote

so what happens on other OS'? what is used, if anything, with TWebBrowser on them? mac, *nix, bsd, etc...

In Delphi's case it's quite simple. No other platform is supported other than Windows. As for LHelp, I think the current "custom implemented HTML viewing widget" is the best solution at the moment. No extra libraries and it will work on all platforms.

But as already discussed. If Gecko is to be used in LHelp, it should be a user selectable option - selecting between Gecko or the "custom HTML component".

Regards,
- Graeme -