Zac Bowling’s Blog

When I read Andreia Gaita’s latest post, I started to tear up and laugh a little as it brought back a lot of painful memories with my experience with fighting it. Andreia, you know all to well my pains and my struggles I had with that code (trying to embed Mozilla externally). I’m so overwhelmed with joy that you got it going. Awesome work that you have done taking my pretty hobbled and badly broken code the rest of the way and making it actually work!

My biggest hurdle in the beginning was trying to figure out how to make this all work given all the requirements. Some of the requirements where more self imposed in what I though it would take to get the web browser control accepted, and others requirements came from other monoers (especially Miguel ). Going through the options, it came came down to forking off a version of the entire mozilla tree and embedding the entire mozilla engine into my wrapper, or calling it Mozilla dynamically. (You can read more about that in previous post). I knew that forking the mozilla tree would be horrible because no body would want to build it and use it (it takes an extra 7mb, about 3 hours to build on most average machines, and you have to manually maintain it). Also there were concerns about littering the source control with that massive beast. That left the only other solution, externally calling the local Mozilla environment on the users machine dynamically, although it was the FAR more complicated solution to make it work (it shouldn’t be and perhaps this project will help that).

In beginning, I was still going through the mozilla code and documentation trying to understand it better. I have written a bunch of patches for GtkMozEmbed, so thats the angle I started attacking it. The Mozilla documentation on embedding is helpful but it was written around the idea of forking the Mozilla tree. I was still trying to understand how to make it work so I went ahead and wrote a version of the embedding control in that fashion (internal wrapper) by forking the gtkembedmoz code and removing almost all the GTK+ references (you can see older bits and peices of that here). I though I could take that version and move it to build externally, however I didn’t realize how many private functions and interfaces are inside Mozilla that gtkmozembed actually used. There was almost no way it was going to work, so I started from scratch.

I was pretty much forced to dive deep into internals of XPCOM. In the process I had to learn the evolution of the Mozilla codebase to understand why things where done the way they are done. This took way to long (I could almost write a small book on the topic now). When I got done, I figured that no body in their right mind (I guess that includes me) is going to want to go through this to just embed Mozilla. Thats when I came up with the goal of making sure that the backend library that I was going to write to bridge Mono and Mozilla would be reusable outside of just Mono if at all possible (a simple embedding interface that exposes basic C exports for people to use).

Then it came down to the build environment. I have experience with witting libraries in the open source/Linux world, and at first I though it was going to be easy. Heck, even my distro even had package config files to save me a bunch of trouble (later I found out that my distro added those and there is no standard package config for developer packages or XPCOM). I got started with an environment that I though would work for everyone and got going writing code. I got it working for while, but half way through development I updated to a new release of my distro. Suddenly nothing would compile anymore. I found out that my distro was including IDL files it wasn’t supposed to in the older version. I was missing IDLs I needed. I did some investigation of other distro setups and found everyone did it differently (vastly different in many cases). This shut any new code development down while I re-evaluated what to do and what code would I be able to saved. I went back and looked at what was frozen and I trimmed down the interfaces I was going to use to as few as possible. After that I went back to the code and started trimming out code that called those interfaces I couldn’t/shouldn’t use anymore and looked for a work around to each one. This put the code in an unstable state where it wouldn’t build again. I hacked and hacked, trying to get it to compile again. I wasn’t even sure when I was done if it was going to work since I didn’t get to test it as I went along. I spent a good month’s worth of free time on it. I finally got it to compile but I was cheating in a few places. My build environment still needed work to stop cheating. I remember only one time that I seen that come up and show something after that after hacking it for a while.

Shortly afterward, I started working for TI and at the same time my laptop decided to take a sabbatical and go off to laptop hospital at Dell, who after replacing my motherboard, happened to wipe my drive and image with Windows (thank you every much Dell! Of course it “wouldn’t boot into Windows”, its called LINUX! Thank god I backed everything up.) I decided to give up working on it and wait until the interfaces changes and patches I submitted to mozilla would make it into the next release version (basically by 2.0).

I haven’t been able to spend the time to get back into it with work taking more of day. I did take some time and finished some work on getting a reusable build environment last month but haven’t been able to dedicate the time to it I wanted to.

Thats where Andreia has stepped up and taken over getting it done and she has done an awesome job doing so. I’m so happy to see it going somewhere with all that time I dumped on it.

Tags: Mono & .NET, Personal

This entry was posted on Sunday, July 1st, 2007 at 7:36 pm and is filed under Personal. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.