Linked by Thom Holwerda on Sat 14th Feb 2009 12:55 UTC
Google A major complaint about Google's Chrome web browser has been that so far, it is still not available on anything other than Windows. Google promised to deliver Chrome to Mac OS X and Linux as well, but as it turns out, this is a little harder than they anticipated, Ben Goodger, Google's Chrome interface lead, has explained in an email. It has also been revealed what toolkit the Linux version of Chrome will use: Gtk+.
Thread beginning with comment 348958
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Why not QT?
by dnas.dnas on Sat 14th Feb 2009 18:58 UTC in reply to "RE[3]: Why not QT?"
Member since:

I think you're confused. Firefox and SWT suffered from emulating GTK+, not implementing it. From what I gather from the article Chrome will be using native GTK+ which will make the interface much more consistent with other GNOME/GTK+ applications.

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.

Reply Parent Score: 12

RE[5]: Why not QT?
by abraxas on Sat 14th Feb 2009 22:42 in reply to "RE[4]: Why not QT?"
abraxas Member since:

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.

Reply Parent Score: 2

RE[6]: Why not QT?
by dnas.dnas on Sun 15th Feb 2009 08:19 in reply to "RE[5]: Why not QT?"
dnas.dnas Member since:

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.

Reply Parent Score: 4