• View
• Edit
• History
• Print

FAQ

Project

Why wxWebKit?

As some of you know, there are already several ways to embed a web browser in a wx application. They include wxHtmlWindow (wx's own implementation of a browser), and wrappers for the various browser engines out there (wxIEHtmlWindow, wxMozilla and wxWebKitCtrl). So why another? There are a couple major goals we couldn't achieve with these other approaches:

• We couldn't get a modern, highly efficient and standards-complaint HTML/DHTML/CSS renderer using wxHtmlWindow due simply to the enormous effort involved. Vaclav Slavik did some amazing work on it, but this is really more than a one man job. With wxWebKit, we get all that out of the box.
• We could wrap the various browser engines into one consistent wrapper, but that 'wrapper' would either be very limited (just let you load pages and do back/next navigation) or would require lots of "engine-specific" coding. Setting browser preferences, enabling editing, adding handlers for different protocols (e.g. myProtocol://myPage) and various other tasks were very browser-specific, it was hard to find suitable API abstractions that would work for all browsers.

I'm sure the question everyone will ask next is, why not wxMozilla or its successor, wxWebConnect? Embedding Mozilla cross-platform has several issues, but the deal breaker is that embedding does not work on Mac with Carbon. There were also several issues with the editing functionality being in a state of decay after the split of Composer from the main engine, which led me to having to spend a lot of my time trying to debug Mozilla rather than wxMozilla, which was quite a daunting task.

Which leads us to wxWebKit. wxWebKit has already been proven to run on Win, Linux, and OS X, uses wx under the hood (and thus can theoretically run wherever wx can), supports editing, has a very clean separation between cross-platform and platform-specific code, has tons of LayoutTests and such to prevent regressions, and has a very welcoming and helpful community who have been very supportive of the wx port (along with the other ports). So we are very confident that this port has a bright future and will bring some much needed web browsing and editing functionality to wx.

Why are you using a gitorious repo instead of WebKit's SVN/git repo?

Actually, you can checkout and build wxWebKit from WebKit's repos as well. However, sometimes changes to common code or other ports in WebKit SVN may break wxWebKit compilation, and so we wanted a repo that would (or should!) always build. To accomplish this, we created the gitorious repo, and we periodically merge with it after ensuring that the wx port builds properly. If you're fine with potential compilation breakages, you're free to use WebKit SVN/git for your repo.

What about wxPython/wxPerl?

wxPython wrappers are already available, and are in the WebKit SVN tree. To generate wrappers, add wxpython to the build command - i.e. build-webkit --wx wxgc wxpython. Make sure you've got the wxPython dev files installed and Robin's modified SWIG installed as well. wxPerl or other bindings are dependent upon someone in the community coming in to help, although this year (2009) one of the wxPerl Google Summer of Code projects aims to create wxPerl bindings for wxWebKit.