To view parent comment, click here.
To read all comments associated with this story, please click here.
Perhaps "emulate" wasn't the correct word to use but you're saying the same thing I was driving at. Firefox and SWT don't call GTK+ directly and their UI code doesn't align very well with GTK+ conventions. Firefox has come a long way and the 3.x versions are much better than previous versions. I haven't used an SWT application in a while but the last time I did it wasn't a very good experience compared to a strictly GTK+ application. Fortunately for Google Webkit has developed into a very portable library with an excellent GTK+ port. There is an abstraction layer that makes creating new bindings for it much easier.
Webkit in fact suffers from the same problems that Firefox does. You cannot use native widgets directly in a web engine. The performance is too bad. (Also, in the case of GTK, positioning your widgets is rather difficult.) Rather, you make your own widget-like system and call the widget drawing API to make your buttons look native. GTK makes this very difficult.
Firefox, in particular, extends this practice to the entire browser. This means they do not have to deal with SWT's problems (the GTK widget model is very poor for wrapping), but the drawing API issues pervade the entire UI. They cannot directly use GTK because they want the UI written with the same, or similar technologies as the web (XUL, Javascript, etc.). This lets them do extensions and themes very cleanly. Also, it means they don't need to write a separate UI for every platform --- GTK+ is not a cross-platform toolkit and is unusable outside Linux.
I imagine Chrome will also want their various platforms to, at least at the highest level, share a lot of GUI code. Different platforms have their conventions, but the core layout of Chrome will probably be constant --- it would be a real chore to maintain three versions of it. Not to mention the fact that, should they do extensions, having to rewrite the extension per-platform would be obnoxious.
However, to manage this, it would mean abstracting over the UI toolkits in some way. Here, they will either run into SWT's issue where GTK's widget model is messed up and cannot be wrapped, or Firefox's issue where "emulating" GTK is nearly impossible.




Member since:
2006-05-27
This is not quite true.
Firefox suffers from trying to hook into parts of GTK+. Unfortunately, GTK+ isn't very well-designed, so it is not possible to tell it to draw a random widget. The drawing API has no way of expressing "get me a picture of a GtkButton at this size". The background color must be premultiplied and most themes require an actual instance of a widget as the detail string isn't well-specified. The result is that, whenever Firefox needs to draw a widget, it must have a hidden instance of that widget, and then it must draw it twice, on both black and white background. Then the pixmaps get pulled over from the X server, every pair of pixel is compared in software to recover the original alpha, the image is sent back to the X server, and only then can it be displayed. QGtkStyle has a similar problem and caches all the pixmaps --- I imagine Firefox does the same.
For added fun, since GTK+ was never designed to be embedded into anything, many themes assume they draw their own background and that's why some of them draw ugly borders at the corners of buttons in Firefox.
SWT suffers from another problem. Unlike Firefox, they actually use GTK+ directly, but wrap it in a cross-platform API. Unfortunately, the SWT widget model is slightly different from GTK+'s (it instead matches that of... pretty much every toolkit on the planet). GTK+ itself isn't very flexible, so SWT has to do many many hacks to get around this. As a result, it gets double the performance hit: once for using GTK+ at all and once more for the hacks.