The future of wxWebConnect

[jonmmorgan]

The Roadmap lists a number of things that are in the future plans, but which are still in progress. Some of those that I am interested in are:
* Support for XULRunner 1.9.2.
* Support for Mac.

Support for Mac it sounds like will hopefully work better with the OSX/Cocoa version in 2.9.x. I don't have a Mac, but one of the key developers on our project does, and so requires Mac support (and can hopefully be persuaded into building and testing it).

Support for XULRunner 1.9.2 is another key issue. XR 1.8 is basically unsupported by Mozilla and fairly slow as well. I would prefer 1.9.2 to be supported because it seems to offer the greatest chance of moving to later versions as they come out (for example, FF 3.7 and XR 1.9.3 is slated to have substantial rendering speed improvement over FF 3.6). However, one of the things that concerns me is how well development will be able to move to later versions. Having a self contained IDL file and header file is great for removing dependence on having XULRunner about before building WebConnect, but means that we can't easily update it to get changes. I initially started working with a newer version of xpidl, but dropped back to a binary of 1.8.1 xpidl when I found all kinds of compilation errors that I didn't really want to solve (I couldn't discover source at the Mozilla site for 1.8.1). My protocol handler changes do not work with 1.8.1 (not entirely sure why), and there's no way I can easily debug that. They do work with 1.9.2. I wonder if what we really need is to generate nsall.idl from a preprocessor that includes the relevant IDL files from Mozilla source and so forth. Then you could (at least in theory) build against different versions of XULRunner in development, as well as creating distributions that did not need XULRunner to build them. Another thing I noticed was that most code you see in Mozilla or on the web are using nsCOMPtrs, while WebConnect uses ns_smartptr. I don't know if this is just a renaming or something more substantial (they have a few more methods, but seem to me to be much the same). I would prefer to use code that looks and acts like Mozilla code, so that then it is more easy to add functionality by viewing Mozilla code, and I would also prefer to be able to upgrade to different versions of XULRunner more easily and use other library functions and interfaces that change from release to release (such as utility functions I have seen for getting the docShell from a context). It seems to me that duplicating all of the code you want will increase the risk of this. I understand that there are some things that don't work in XR 1.9.2, and some of them I've perhaps bumped into, but in the main I haven't yet had any problems with using it and I think it's the right way forward. Do you have any list of the kind of things that break?

From a development point of view, another key question is: How are Kirix supporting WebConnect? From the outside, all I see is a version 1 release, which I assume is the release announced at wxWidgets in July last year. I have seen several patches and method implementations floating around in different forum posts that I would like to apply and use, and I of course have my own development version (which I will probably maintain for the foreseeable future), but for me the biggest problem is visibility: what is Kirix doing with WebConnect now and what do they plan to do in the future? Are future releases planned? Is there work in development that we should know about before we go to fix bugs in the released code, and if so can we access that anywhere?

Sorry to sound so questioning, but in initial testing I have found WebConnect to be the best renderer for wxWidgets by a long way (and if XR continues to improve it should stay that way) and I want the freedom to make it better and more useful for me without treading on too many toes or maintaining my own independent branch of the software for ever (though if Kirix were not interested in maintaining it that might be the best solution).

[jerry_mouse]

No one from Kirix cares to reply to this topic.
It seems that they don't care about this library anymore, so I think you can fork wxWebConnect and make a sf.net's home for it so other people can keep on improving it.

[Ben]

Hi there,


Someone posted a patch for Mac support a while back, which I'm going to take a look at soon. You might want to investigate this patch, as it is reported to get the library working on the Mac platform.

@jerry_mouse: We care very much about wxWebConnect. I hope you've noted today's release, which includes XULRunner 1.9.2 support. However, as with any free software project, feel free to fork it and improve it.

Best,
Ben

[jonmmorgan]

I have not seen any patches for Mac support in either the patches forum or the thoughts and feedback forum. All I've seen is Robin Dunn's post asking about it and saying it didn't work when he tried it.

[psc]

2 words: MINGW support

[garrizano]

2 words: MINGW support

Yes, please.