Zac Bowling’s Mind

I’ve been hacking on libmozembed all week. Complete with the tons of headaches and victories that go along with it.

I came up with a pretty cool model for doing reverse pinvoke in a massive fashion. Instead of creating a delegate around each method and then pass each one to the unmanaged layer one by one, I decided to go the route of creating a struct strictly full of delegates to hold all my callbacks. I marshal that struct on the unmanaged side to a struct full of function pointers. Because its a little tedious writing a new delegate around each function, I went one step further and wrote an interface that declares all the functions required for each off the callbacks and wrote a nice little static little function wrap any instance of that interface in each of the required delegates. It’s nice and clean if I don’t say so myself.

I’m currently wrapping up a bunch of the interfaces in mozilla to give us full control in the managed layer over things instead of the wrapper automatically assuming the most generic implementation like I was doing before. I decided that this was the best route when I hit a few places in the code like the profile and window creator and some of the other services I have to create anyways. I’m even opening up some the basics so that when the xpcom stuff is ready, we should be able to integrate XPCOM layer with everything. (Mostly just opening up my XPCOM wrappers and providing a few functions to get my running instance of the core XPCOM services that I’ve already created for use by the XPCOM wrappers)

I’m really moving to the route of integrating XPCOM to supplement everything past the basics. I think it’s going to be the best solution in the end. I think I evolved through the entire thought process that the Mozilla and Java integrators went through over the past 6 years in just a little less then a month and came to a very similar conclusion in the very end. The greatest part is that we can do it better then Java could ever do because of limitations with JNI and in what Java can support itself. Mono has Reflection.Emit and compared to JNI, pinvoke rocks. Where Java has always had to generate a JNI stub for (up until the latest breaking code and very unstable code), we do not need to thanks to the magic of Reflection.Emit.

I’m completely avoiding any requirement on any bit of the XPCOM wrapping stuff to get the use the basics with the browser embedding. It’s just when you want to access things like the DOM, the printing interfaces, the spell checker, and the thousands and thousands of other goodies, will you need to use the XPCOM interfaces. When its done, everything should play well and while still manually handling the gecko embedding parts. It will also make things more stable and faster in the end when it comes to straight up gecko embedding. Maybe some day in the future (maybe next year or something) we can even just go right to XPCOM for doing everything.

Also in a high level respect, I noticed that I’m going through the exact same struggles that the Mozilla ActiveX control guys went through. They wrap Microsoft’s IE api as well. However where they have COM and only work on Win32, I’m wrapping it at the layer that tlb2asm eats it up. It’s a bit interesting to say the least.

Oh well. Back to work.

I’ve done a bunch today… Just after posting my last blog post on libmozembed, I spent a few hours and knocked out milestone 2.5 and 3.0 in nearly 1/5 the time I though it would take. No more Mozilla SDK required now that I’m dynamically invoking xpcom’s glue.

YEPPIE!

Now time to clean up the binding, add a few helper functions, and get to work on the rest of everything on the managed side.

Subversion

Subversion is finally putting the last nail in the CVS coffin it seems. All but GNOME and Mozilla’s CVS are the only two of the most mainstream active projects I know that still stuck using CVS. I can’t figure out why GNOME hasn’t switched yet, but I know its going to be a bit of trouble for Mozilla with the make scripts, lxr, and anonymous mirrors.

Also the ViewCVS project has now been renamed now to ViewVC as of 1.0, and has taken up residence on tigris.org with SVN itself.

Bye Bye MSDN

After having an MSDN subscription on hand for over 10 years, my MSDN sub. is now gone, expired, and dead. I just couldn’t figure out why I needed it anymore. I’m sure I will come to a point where I will need it again, and I might buy a new one in the future. So far I’ve done just fine without it for over 4 1/2 months without it.

Maybe, I might buy another next year… blah… maybe

Mozilla control for MWF

No more compile errors from Mozilla’s headers! Whoohooo. Still lots more work to do. I have to thank the Epiphany guys and the Galeon guys a ton for their help.

Seems I have to directly break some of the documented rules with Mozilla’s embedding API because some of the headers in Mozilla don’t follow them either in some of their unfrozen APIs. From what I gather from everyone though, it’s not that bad calling the unfrozen interfaces in there. Usually requires a few nights of hacking after every major release of Firefox/Mozilla to keep everything working and I don’t mind doing that. Not like we are going to be doing anything that special (hope those aren’t famous last words). I’ve got Firefox 1.5/Seamonkey/XULRunner support right now and I’m nearly there for supporting backword compatablity with Firefox 1.0/Mozilla 1.7.

I was going to go crazy on features since its so easy to tie in anything in there, but I don’t know which part will get rewriten in the next Mozilla based incarnation to be released. I used gtkembedmoz as the main basis for about 50% of my code, so I already support just everything it offers already. I’ve also added support for getting more information from the click and key press events, and I’ve added the ability to disable a few features that you might not want (frames, plugins, images, meta-redirects, etc). I even added support for forcing a repaints, and accessing and consuming a lot of events like before a URL change or on any click or keypress that happens.

However, currently, I’m debating on adding:
* Print/Print Preview support
* Access to the clipboard and the selected text in the window from code
* Access to cookies, history, cache, etc.
* Access to Mozilla’s configuration settings (for reseting the default font’s, text size, etc)
* Access to evaluate Javascript (even get a boolean return code) in the page and get even catch Javascript error callbacks (Galeon does this).
* More networking control (proxy, file handlers, etc).
* DOM integration - will have to be with the XPCOM bridge (unless someone wants to wrap the huge root nsIDOMElement class, the root of all elements, in C for me :-P)

All these features, with the exception of the DOM access, is very easy to add, however the more I add, the more any change in Mozilla’s codebase in the future could make it easier to break.

I think I’m going to play it by ear when wrapping the WebBrowser API in MWF to see where I get too.