Because there's been a lot of interest lately in a TWebBrowser-like component for Lazarus, I went ahead and ported Takanori Ito's Gecko SDK for Delphi.
The ported code is here:
http://web.fastermac.net/~MacPgmr/Lazarus/Download the GeckoPort .zip file, then try installing the GeckoComponents.lpk package and test the two .lpi projects (in SampleApps).
Takanori's SourceForge repository is here:
http://d-gecko.svn.sourceforge.net/viewvc/d-gecko/I also ported and included the two sample apps from an earlier version of his SDK.
Status report:
***Windows***
Delphi 7: Packages install fine and both sample apps compile and run fine.
Lazarus 0.9.28.2 / FPC 2.2.4: FPC can't compile the TGeckoBrowser component. But the BrowseWin.dpr does not depend on the TGeckoBrowser component and compiles and runs okay.
***OS X / Intel***
Lazarus 0.9.28.2 / FPC 2.2.4: FPC compiles TGeckoBrowser component okay (unlike FPC on Windows). But neither app runs. The InitWindow call to initialize the browser requires a native window to be passed in. A Carbon window won't work since Gecko is expecting a Cocoa NSView (presumably). Since the BrowseWin.dpr app only uses TForm, I tested it with the rudimentary Cocoa widgetset, passing in the TCocoaForm's MainWindowView (declared as NSView), but the app just crashes.
***OS X / PowerPC***
Lazarus 0.9.28.2 / FPC 2.2.4: The code generated by FPC causes an assembler error, something I've never seen before. End of test.
Tasks for those interested in getting TGeckoBrowser working cross-platform:
(1) Test on Windows with more recent compiler builds to see if apparent FPC bug has been fixed.
(2) Test on Linux to see if passing the TGeckoBrowser's or TForm's Handle is the same as passing a GTK window, or whether the window pointer has to be obtained indirectly from the widgetset controls as with Carbon and Cocoa.
On Linux you may need to change the code to specify the correct path to libxpcom.so. See XRE_FindGRE in nsXRE.pas and GetGREDirectoryPath in nsInit.pas.
(3) Takanori's Delphi code for determining the location of installed Gecko libraries does not find Firefox 3.5's DLL's on Windows, so for now I just hardwired the location in the code. Someone could test to see whether an installation of XULRunner sets the registry the way the code expects. Versions of XULRunner for all platforms are here:
https://developer.mozilla.org/en/XULRunnerOn OS X, this installs XUL.framework under /Library/Frameworks.
Note that on OS X, I launched the test apps from a script (included) in order to set the DYLD_LIBRARY_PATH variable to point to XUL.framework. I also tested it against the Gecko libraries included in /Applications/Firefox.app.
Please report your results here.
Thanks.
-Phil