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 348885
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Why not QT?
by segedunum on Sat 14th Feb 2009 14:56 UTC in reply to "RE: Why not QT?"
segedunum
Member since:
2005-07-06

They didn't say that QT was bad... they said they wanted to use the native toolkit.

What native toolkit would this be, as Chrome by definition doesn't have one as a cross-platform application?

While it's not as clearcut as windows or mac os x, gtk/gnome has more users than qt/kde, so it makes sense to use that as "native".

While I won't debate the number of users thing (not really at issue here), it doesn't get away from the fact that porting a cross-platform application to specific native platforms, and have it work in the same way, is a world of hurt and pain we have already been through with Firefox and SWT on Linux.

You end up being a third class citizen behind the platforms and operating systems that have the most users ;-).

Reply Parent Score: 8

RE[3]: Why not QT?
by abraxas on Sat 14th Feb 2009 15:36 in reply to "RE[2]: Why not QT?"
abraxas Member since:
2005-07-07

What native toolkit would this be, as Chrome by definition doesn't have one as a cross-platform application?


Chrome isn't cross platform...yet. It was built with a lot of Windows specific libraries.

While I won't debate the number of users thing (not really at issue here), it doesn't get away from the fact that porting a cross-platform application to specific native platforms, and have it work in the same way, is a world of hurt and pain we have already been through with Firefox and SWT on Linux.


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.

Reply Parent Score: 2

RE[4]: Why not QT?
by dnas.dnas on Sat 14th Feb 2009 18:58 in reply to "RE[3]: Why not QT?"
dnas.dnas Member since:
2006-05-27

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[4]: Why not QT?
by segedunum on Sat 14th Feb 2009 21:43 in reply to "RE[3]: Why not QT?"
segedunum Member since:
2005-07-06

Chrome isn't cross platform...yet. It was built with a lot of Windows specific libraries.

Hmmmm. So it's 'native'..........to Windows? Kind of the point really. It tries to be native, but it isn't at all.

Firefox and SWT suffered from emulating GTK+, not implementing it. From what I gather from the article Chrome will be using native GTK+....

No. They're not emulating it at all, and that's the problem. They are wrapping it so they can use 'native' system calls on each platform.

...which will make the interface much more consistent with other GNOME/GTK+ applications.

That won't happen, because they will have to make cross-platform trade-offs to make it work across all platforms.

Reply Parent Score: 5