That was a concern I was having myself trying to maintain Gecko#, the gtkmozembed wrapper for Mono and gtk#, which is used in a bunch of apps like Beagle, Blam, MonoDevelop, MonoDoc, our ASP.NET Editor, and a bunch of others. The trunk is pretty buggy and pretty messy lately and I'm having to go back investigate recent bugs.
What I'm doing though is that I've started working on a port that can move us off at least off using GtkMozEmbed and to something that can be built externally from the Mozilla tree and linked dynmaically, but provide everything it does currently, as well as a bunch of other interfaces. I'm building it off the new Gecko SDK builds from XulRunner, now that they started that back up. I'm designing it be a simple wrapper that exports to basic C exports and can be built on any platform instead of depending on Gtk+ as the GFX toolkit and only working on Linux. Originally I started so we can use it to power the WebControl backend in our version of System.Windows.Forms on Linux, Mac, and Windows natively, but now I'm also investing how it can also power the backend to Gecko# in the future as well and then make it possible so that we interoperate with the Mono XPCOM bridge when its ready (also using a single Init_XPCOM call to start up Mozilla for both the bridge and WebControl) I'm designing it to be simple while still being as veristal as I possibly can. My goal is to have an API that is expandable in the future without breaking API/ABI compatabilty. I'm not limiting it to just my use so that possibly if someone want to rewrite WxMozEmbed or anything against it in the future, they could. Things we need in Mono are things like DOM access, dialog and new window overriding, custom stream handling to pipe data in, progress notifcation callbacks, and various other things, some of which we can't do directly in GtkMozEmbed (without Uber hacking), but are going into my wrapper. Its similar to the Java embedding wrapper's design (which was a gtkmozembed fork) except it doesn't have to be built inline with Mozilla. If you remember back a year or two, I was the last one to update the bug related to the Win32 hack to get GtkMozEmbed working on Windows. However after working with it more and understanding the nature of the hack better and how the focus model for gtkmozembed was taking for granite the fact that the controls in the window are also Gtk components down in the GFX layer, I decided to get away from trying to maintain that beast of a work around (Tor the "GTK+ Win32" guy did as well when looking at it for Novell for possibly using it to port Evolution to Win32). If you need something more then it provides and if you have the time, I suggest avoiding gtkmozembed and writing your own embedding wrapper for exactly what you need (a little bit of a learning curve getting setup but its easy once you enviroment is setup). My library will not be ready for primetime for more then a few months, but you can check it out in the mono svn if you are curious in the "mozembed" module (oops, what is there is about 6 months old on the public svn today). Hope that helps. Zac Bowling http://zbowling.com/ On 26 Mar 2007 06:28:07 -0700, "Marco Pesenti Gritti" <[EMAIL PROTECTED]> wrote: > Hello, > > we are using gtkmozembed to develop the OLPC browser. We recently > upgraded to the trunk because the resolution independence features are > essential on a 200 dpi screen. > > Mozilla 1.9 is looking pretty good but we have been hitting several > bugs specific to gtkmozembed. We had to apply several patches to > comment out the new code and that's not a good sign. > > We are interested in contributing bug reports and patches but we are > deeply concerned about the direction the gtkmozembed development has > taken on the trunk: > > * A lot of new code has been committed in big chunks, without any > apparent review process. > * The API is growing without control. The additions doesn't appear to > be well thought and the result is really messy. > * We are duplicating a lot of code. Global history for example or text > selection. > * We are breaking working features, for example file pickers and text > selection. > * Bug reports about the new code are assigned to nobody and ignored. > * The approach seem to wrap most of the embedding API in C. I think we > should rather keep gtkmozembed a simple widget exposing the basic > functionality and allow embedders to use the full xpcom API in C++, > pyxpcom or whatever. > > Can we revert to 1.8 state, discuss the direction and restore the > review process for patches that goes in? I don't want to sound blunt > but... that's the only way I see to restore sanity. > > Marco > > _______________________________________________ > dev-embedding mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-embedding _______________________________________________ dev-embedding mailing list [email protected] https://lists.mozilla.org/listinfo/dev-embedding
