Gtkembedmoz/Gecko# for Win32 lives again!
Thats right. Gtkembemoz (or “gtkmozembed” depending on where you look or who you ask) lives again.
It’s been about a year since I got a build going again but I’ve worked out most of the kinks. Screenshots soon…
After I get this release worthy, I’m calling it my last release in this incarnation except to maintain compatibility with newer releases of mozilla/firefox. No big bug fixes with rendering or display issues.
Why, you might ask? Well gtkembedmoz works in Win32 GTK+ because of some amazing hacks. They are some really great hacks though, and I say they are release worthy, however like with many hacks, its a hack, and a hack that goes against the basic assumptions of how things should work. I plan on working on some for fundamental changes lower level inside gecko (inside the gfx layers) that would render almost all of these hacks obsolete. To understand why you have to understand what is really happening underneath.
The hardest part is that the basic assumption with using gtkembedmoz is that you are embedding inside a GTK+ app and the gecko engine that you are embedding is based on GTK+. However on the Win32 version, you are using a GTK+ app but embedding a gecko engine that use the native WinUI based GUI. This cause some really interesting issues.
One of the greatest parts of mozilla code base is that they have abstracted the basic native UIs on all the native OSs they support. WinUI on windows, GTK+ 1 and 2 for Linux, QT (experimental fork) for KDE users, Cocoa for Mac OSX, Mac’s old native gui (pre OS X which is now dead), BeOS (mostly dead), and few others. That means that when you see a text box embedded in a page, its going to be the native one (or nearly the native one based on native elements of your OS) for your OS. This allows mozilla to take some short cuts by using the native facilities provided by the GUI framework instead of having to handle them all on its own in most cases.
However, when embedding gtkembedmoz in Win32, you break the native bounds of each of the GUIs. The biggest bug that you run into is maintaining focus across the UI bounds (why there are so many hacks to fix this). You also run into some issues with embedding plugins (flash, PDF files, quicktime, etc…). Also the themes don’t persist with the native elements. I noticed that my scrollbars don’t match. Not broken or anything but annoying.
The best solution would be to get gecko to use GTK+ as well on Win32. It’s no small task. It means ifdef out all the X11 stuff out for the win32 version of the GTK+ abstraction code and coming up with some alternatives. I’m sure some drawing issues will come up as well, and plugins will have some issues but its far more elegant then trying to hack WinUI together with GTK+.
Also just to have a GTK+ of Firefox on Win32 would be cool.
Tags: Linux, Mono & .NET
March 6th, 2006 at 10:56 am
Isn’t the firefox 3 plan (what’s currently the Trunk code) of going with a thebes/cairo backend going to solve this problem for the most part. It would seem odd to go back to a gtk+ version of firefox for win32… or are you talking about a more immediate solution based on firefox 1.5/2.0?
Thanks for all your work on this. It’s much appreciated!
-woo
March 9th, 2006 at 11:52 am
Well, You need any help w/ the gtkmozembed stuff, I’m about to port it to windows myself. I don’t think it’ll will be that hard.
Also, have you checked out http://severna.homeip.net/gtkmozwin32.php
April 3rd, 2006 at 11:48 pm
Wouldn’t the simplest solution be for the Gecko engine to support some kind of flag that lets a client application set whether it should use native rendering or not? Or perhaps some pluggable way to force your renderer on to Gecko instead of it automagically choosing the native OS rendering methods.
May 11th, 2006 at 5:08 pm
By the way, do you think it would be possible to use the gtkembemoz - Win32 in a Delphi Win32 based app. I know that Delphi can make calls to the lib2xml libs once wrappers are written. But not sure how the actual control could be embedded onto the Delphi form designer.
There currently is an ActiveX control that can be used in Delphi, but they don’t support all the features and the API you must learn is actually based on MS WebBrowser API, yuck.