wxWebConnect 1.1 Released

[Ben]

Hello all,

Kirix is pleased to announce the availability of wxWebConnect 1.1 -- a new version of the popular library for wxWidgets that enables developers to quickly integrate advanced web browser capabilities.

It wraps up functionality exposed by the Mozilla Foundation's Gecko engine (XULRunner) into a set of user-friendly classes to: embed browser controls, search web content, print web pages, interact with the DOM, implement custom content handling for different MIME types, issue POST calls using the current browser state, etc. Notably, with this library you can also embed all of your favorite Firefox browser plug-ins into your application.

New features in this version include:

* support for xulrunner 1.9.2
* better profile support
* better printing support
* many bug and crash fixes
* works either with xulrunner 1.8 or 1.9.2, your choice

We're looking forward to incorporating the many patches that have been posted on our forums in the upcoming releases in the next weeks. For this release, we considered it critical to get support for XULRunner 1.9.x into the field.

With other libraries in the past, embedding a web browser control has proven a daunting task, often involving compiling seemingly countless sub-dependencies. We've gone out of our way to make sure that getting a browser control up and running in your application is as easy as possible.

More information can be found at the wxWebConnect project page (http://www.kirix.com/labs/wxwebconnect.html). A short demo video and some screenshots can be found here (http://www.kirix.com/labs/wxwebconnect/screenshots.html)

We've released the full source code under the wxWindows license, so please go ahead and use this library in your own applications freely.

Comments and criticisms are welcome.

All the best,
Benjamin I. Williams
Kirix Corporation (http://www.kirix.com)

[jonmmorgan]

Thanks for making this release.

As I think you know, I have been using a modified version of wxWebConnect with XULRunner 1.9.2 (I have been maintaining it on Github for convenience [http://github.com/jonmmorgan/wxwebconnect/], and you are welcome to take any of the changes from there, though some of them have been hacked in more than put in with care).

Executing a script does not work with XULRunner 1.9.2 and wxWebConnect 1.1. The UUIDs for nsIScriptSecurityManager and nsIScriptContext (at least) are the UUIDs for 1.8.x, and have changed in 1.9.2. This is part of the reason why I feel it would be better in some way to include the IDL files and the header files from a XULRunner SDK rather than duplicating all of these in a separate file (though I understand it is probably much easier to build and distribute this way). I added support for executing a script in XR 1.9.2 at http://github.com/jonmmorgan/wxwebconne ... 51bdc8e4bc, though I'm afraid I made such a mess in that commit that I'm not entirely sure what I did (I think it was just replacing the IDL records in nsall.idl and webcontrol.cpp of all the interfaces used in Execute() with the ones in XR 1.9.2 SDK).

[Ben]

Hi Jon,

Wow, great. I'll look into integrating that change of yours to allow scripts to be run.

The logic for the idl files was simple: We wanted to allow people to be able to use XULRunner without having to link to the xpcom glue library, because it can be quite difficult to get compiled, and the provided binary glue library files don't link with every compiler out there. It seemed like too much of an imposition to force people to download and compile the entire mozilla true just to get the xpcom glue library compiled and working.

We went for a solution that allows runtime binding to the XULRunner libraries. wxWebConnect even provides simultaneous support for both the 1.8.x and 1.9.x versions of XULRunner, so these can be switched even after compilation of the main source.

The downside to this is simply that it was a lot of work to do all of the glue work ourselves. So, you are quite right. Upgrading to 1.9.x from 1.8 was initially fairly straightforward, but almost all of the more advanced 1.9 features, such as SSL warnings, were painstakingly difficult to get working.

I'm looking forward to integrating your work.

Best,
Ben

[jonmmorgan]

I do understand there are problems going the Mozilla way, and I'd have to say it was great how well and how easily wxWebConnect compiled. As I already have to compile wxWidgets, wxPython and wxWebConnect I'm in no hurry to add XULRunner to the list. However, what I was suggesting at first was a bit more modest:
1. Create files to be pre-processed to produce nsall.idl (and perhaps some of the headers).
2. Distribute them after they have been pre-processed.

e.g.
nsall.idl.in
#include "nsIProtocolHandler.idl"
#include "nsIScriptSecurityManager.idl"
...

I would only suggest using IDL files and headers in the XULRunner SDK distribution. That's not too much of an imposition on developers of wxWebConnect, and doesn't necessarily need to affect users of wxWebConnect (as they get nsall.idl and nsall.h just as they do now, but it has already been run through the pre-processor). What this means is that when you build with a different version of XULRunner and any of the interfaces have changed their IID it all just works (well, hopefully). No more need to track down which interface has changed and patch in a conditional everywhere that interface is used. If you wanted to support multiple versions of XULRunner (which is probably a good idea) you could then have it generate a few versions of nsall.h (using different versions of the XULRunner SDK) in nsall.181.h, nsall.190.h, nsall.192.h, etc., then just make nsall.h something along the lines of:
#if defined XULRUNNER_VERSION_181
#include "nsall.181.h"
#elif defined XULRUNNER_VERSION_190
#include "nsall.190.h"
#else
#include "nsall.192.h"
#endif

That's just a rough sketch, and I'm sure it would have problems and wouldn't work as smoothly as I envisage, but I think it could be a neater solution if it could be made to work.

The situation with relying on XULRunner headers rather than IDL files is a little less pleasant. They can and do drag in almost anything from Mozilla. I would still like to have something like the nsall.idl.in I propose for headers for capturing things like nsIScriptContext and friends which are currently embedded in webcontrol.cpp and have changed quite a bit between 1.8.1 and 1.9.2. However, it does have problems. At the moment, I have a function:
wxString wxWebControl::ExecuteScriptWithResult(const wxString& js_code)

which works and is fairly handy. However, getting it to work took a morning of trying to figure out the right things to call in Mozilla, and then a long afternoon trying to figure out how to compile and link the resulting changes with MS Visual C++ Express. In the end I got tired of digging through the XR header files finding everything to make it work, so I just included the XR headers in my include path, but then it utterly and completely refused to link. In the end it turned out I needed to include the (possibly private) Javascript DLL js3250.dll, and then create an import library for the functions I wanted from it:
LIBRARY js3250
EXPORTS
JS_ValueToString
JS_GetStringBytes

This "solution" appears fragile and not the right way to go (I haven't had a chance to test on any platform other than MSVC++), but I'm not sure how much else we can do if we really want to get at XULRunner internals that they do not appear to have exposed interfaces for (even in the DLL) and which it may be too much work trying to integrate the glue into wxWebConnect in the way you have done (I have no idea if it would actually be too much work).


All of this is just thoughts, and I haven't tried implementing, so I don't know that it will work or be practicable. However, it does seem to solve the problem of IIDs and interfaces changing in different versions of Mozilla. It could make wxWebConnect much closer to only having to worry about source compatibility, not binary compatibility which Mozilla are apparently quite happy to break.

[wittend]

A very informative discussion.

I too am happily surprised at how easily wxWebConnect compiles. I hope that it can remain that way. Mucking around in IDL can surely be painful.

But it appears that I should not be shocked that that wxWebControl::Execute() doesn't work. This is important to my projects, too. So I eagerly await its resolution.

Thanks,

Dave